From nobody Wed Feb 1 06:59:09 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BEE129E54; Wed, 1 Feb 2017 06:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szRE8rg1XOP6; Wed, 1 Feb 2017 06:59:06 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 BA091129E4F; Wed, 1 Feb 2017 06:59:06 -0800 (PST) Received: from mbp-4.local ([IPv6:2601:647:4201:9e61:c191:d259:1e66:4d2b]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v11Ewscx011131 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 1 Feb 2017 14:58:55 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:c191:d259:1e66:4d2b] claimed to be mbp-4.local To: Stephen Farrell , The IESG References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> From: joel jaeggli Message-ID: Date: Wed, 1 Feb 2017 06:58:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="irNG4eH1FmULQWpnlSCoA9rh6Omue6dBr" Archived-At: Cc: oauth-chairs@ietf.org, draft-ietf-oauth-amr-values@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 14:59:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --irNG4eH1FmULQWpnlSCoA9rh6Omue6dBr Content-Type: multipart/mixed; boundary="Igbu9H2lhnVGPgk6fGKuNQlxQOxkRUMVb"; protected-headers="v1" From: joel jaeggli To: Stephen Farrell , The IESG Cc: Hannes.Tschofenig@gmx.net, oauth-chairs@ietf.org, draft-ietf-oauth-amr-values@ietf.org, oauth@ietf.org Message-ID: Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> In-Reply-To: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> --Igbu9H2lhnVGPgk6fGKuNQlxQOxkRUMVb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/31/17 8:26 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-oauth-amr-values-05: 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 https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This specification seems to me to break it's own > rules. You state that registrations should include > a reference to a specification to improve interop. > And yet, for the strings added here (e.g. otp) you > don't do that (referring to section 2 will not > improve interop) and there are different ways in > which many of the methods in section 2 can be done. > So I think you need to add a bunch more references. Not clear to me that the document creating the registry needs to adhere to the rules for further allocations in order to prepoulate the registry. that is perhaps an appeal to future consistency. > > > --Igbu9H2lhnVGPgk6fGKuNQlxQOxkRUMVb-- --irNG4eH1FmULQWpnlSCoA9rh6Omue6dBr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAliR964ACgkQ8AA1q7Z/VrKVhQCeJtjt1mn6islI4UFsZJEdVBvd 8MwAnjon37WGZCHC/EiYTNEPTkGBiiGK =k02t -----END PGP SIGNATURE----- --irNG4eH1FmULQWpnlSCoA9rh6Omue6dBr-- From nobody Wed Feb 1 07:03:03 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549EE12945D; Wed, 1 Feb 2017 07:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qul2JA77xUCq; Wed, 1 Feb 2017 07:03:00 -0800 (PST) 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 3C26A1289C4; Wed, 1 Feb 2017 07:02:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 98395BE2C; Wed, 1 Feb 2017 15:02:57 +0000 (GMT) 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 oa2EHYzA_H_h; Wed, 1 Feb 2017 15:02:57 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B75C7BE4C; Wed, 1 Feb 2017 15:02:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485961377; bh=aVYcThReaQvW7MmmH4hlM2bJzTTxZ1bSCTBBQzIyvNc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ADl33WV4gPK8ORh4OtrDOFzwkUNVJJ3uGZCoJrJyRfIofVSXIjI0bv/m3Ij+SpXSc r1oJ5I49fM52Na9XKedBxX1Tvjqub8q/NhRWPMfxnGbhiI8gihb2ooLLRNZgY7obBs DIDf2SSYqMqhk38ZjsNzwdlcrbIe5kKkV219Nack= To: joel jaeggli , The IESG References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 1 Feb 2017 15:02:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ilDmO9WqvMoBUJUogbtxJPjVIqTSsrn7k" Archived-At: Cc: oauth-chairs@ietf.org, draft-ietf-oauth-amr-values@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 15:03:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ilDmO9WqvMoBUJUogbtxJPjVIqTSsrn7k Content-Type: multipart/mixed; boundary="JggNB17Xma8CPdPwcgJLCP6bVWXmxdOKI"; protected-headers="v1" From: Stephen Farrell To: joel jaeggli , The IESG Cc: Hannes.Tschofenig@gmx.net, oauth-chairs@ietf.org, draft-ietf-oauth-amr-values@ietf.org, oauth@ietf.org Message-ID: Subject: Re: Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> In-Reply-To: --JggNB17Xma8CPdPwcgJLCP6bVWXmxdOKI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 01/02/17 14:58, joel jaeggli wrote: > On 1/31/17 8:26 AM, Stephen Farrell wrote: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-oauth-amr-values-05: 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 thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> This specification seems to me to break it's own >> rules. You state that registrations should include >> a reference to a specification to improve interop. >> And yet, for the strings added here (e.g. otp) you >> don't do that (referring to section 2 will not >> improve interop) and there are different ways in >> which many of the methods in section 2 can be done. >> So I think you need to add a bunch more references. >=20 > Not clear to me that the document creating the registry needs to adhere= > to the rules for further allocations in order to prepoulate the > registry. that is perhaps an appeal to future consistency. Sure - I'm all for a smattering of inconsistency:-) But I think the lack of specs in some of these cases could impact on interop, e.g. in the otp case, they quote two RFCs and yet only have one value. That seems a bit broken to me, so the discuss isn't really about the formalism. S. >> >> >> >=20 >=20 --JggNB17Xma8CPdPwcgJLCP6bVWXmxdOKI-- --ilDmO9WqvMoBUJUogbtxJPjVIqTSsrn7k Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYkfigAAoJEC88hzaAX42ir6IH/0IUq5lO1MvgLrkwgGvUlc2v 4FmTszjyJcDXcl6ZHWauKcOWsYhEi40ZzfLItavJI3zij2QdFNrqrMWM311aVKEJ Kgbv1u5HLKWm8m+IS3fSmp1oeZumn9DMqf0DskTAFdqGUoOgnF7Qr+2370Lou8ah 0O6OJ/MgKInNeH/haHe8vgdefRr8pki4f68fGaV4rxesJTTkZY2sRdGt31eIXrXy KAx7EGx+krfeEBSHCXaAFaAg/rVByK+I9bbP/5Rm2Ghkd4iTvKkk2Q3VEXhFYCW6 z4JEs+CuhDBLwSUeEntTXVAnj5zMRDUPvr05xGXUVEsd2P4LzQRYgQ8MtI6lSPE= =ma67 -----END PGP SIGNATURE----- --ilDmO9WqvMoBUJUogbtxJPjVIqTSsrn7k-- From nobody Wed Feb 1 09:01:08 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F821294DF; Wed, 1 Feb 2017 09:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1fnrxFCZUkB; Wed, 1 Feb 2017 09:01:01 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0126.outbound.protection.outlook.com [104.47.33.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD421294E8; Wed, 1 Feb 2017 09:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CBCJr0443dN5vq91AGps9dv3DLqfUb2fHt7/5a8ewpw=; b=Hv7eLt+ZZdIhfaTldXAvEI5zwgR9Z2bTIx7EHdfAbUuVOLb3O8HF0/lgUZWb+tnIUNYJs174Js+ioMuva7xNQy5WZB6zK0XUBHzCIjWXqluSFRr9KrWNpWGcFlfDOCvp1Jz/gQ731t+WEQjw//4ntpcvrTru0+PmCKOAIuKc31M= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2354.namprd03.prod.outlook.com (10.166.74.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Wed, 1 Feb 2017 17:00:48 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0874.021; Wed, 1 Feb 2017 17:00:48 +0000 From: Mike Jones To: Stephen Farrell , joel jaeggli , The IESG Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) Thread-Index: AQHSe97H5hXZpqeBE0CT6lHMY4yQFKFUP6sAgAABIQCAAB5D0A== Date: Wed, 1 Feb 2017 17:00:47 +0000 Message-ID: References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.95.25] x-ms-office365-filtering-correlation-id: bb5b53a1-f4f6-4f86-7644-08d44ac3ded0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR03MB2354; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2354; 7:tdts7GLzKM1oBtXBFdu9JN6xIagCytMSJ3g0gOSg2NL9aWRachhm4bvcGdOMGyLbe2tMvq5Tp4ufiI32LPAGGAkE7yeIN0gNYDqb95krENFXIw0zmamXUcD+LY+3x2j8FFH8/ZPPRp2yX33agoR7o57bhrC8SeS+4TpbChDmu9W1TsWez5La5nxZWee/kqvxl26gcBwPGHPCwX+XbZbEPvyWsbOAmyrfFTAmEkBa9tQm0o+hy0JGAhtvJ4HhGK54T8BhwdAo74I4nHSfyl6p6Mva7wNZead0CW4CQ1UwQH6SuGf83KcosQKZpkI7KwWK/iomFERg21WBogfm++d+vo6bqYWl87EHOGK/xKD9dCjuebw2HLA1l5XI9ut1RP1EuweHpRsSjitKF/eB97A+QixBlNSTsyLIsyr4ybH/smPa9mdANpuvohI1d1wuhmkXAV1RSMiPZWN/pCpTfFinCW4bxMgb8hffBaPFW9venn2iYuoBHnffUI+B+mwwQvSfThlKZ/K16hqEuFdqYJYWvLyXniQroqifGI9zf0a62wL15X3xAeyT5zoJxrfRJaFc x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(20161123558025)(6072148); SRVR:BN3PR03MB2354; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2354; x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39840400002)(39450400003)(39410400002)(51444003)(51914003)(377454003)(40224003)(189002)(199003)(24454002)(13464003)(6116002)(10090500001)(53936002)(97736004)(5001770100001)(3846002)(3280700002)(8990500004)(5005710100001)(2906002)(4326007)(2950100002)(5660300001)(106116001)(102836003)(7736002)(10290500002)(230783001)(305945005)(106356001)(105586002)(7696004)(6306002)(54356999)(9686003)(54906002)(3660700001)(25786008)(76176999)(6436002)(77096006)(229853002)(6506006)(74316002)(189998001)(55016002)(38730400001)(99286003)(68736007)(8676002)(101416001)(86362001)(122556002)(81156014)(92566002)(86612001)(81166006)(8936002)(50986999)(33656002)(66066001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2354; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2017 17:00:48.0662 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2354 Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 17:01:03 -0000 VGhhbmtzIGZvciB0aGUgZGlzY3Vzc2lvbiwgU3RlcGhlbi4NCg0KVG8geW91ciBwb2ludCBhYm91 dCAib3RwIiwgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzY3Vzc2VkIHRoaXMgdmVyeSBwb2ludC4gIFRo ZXkgZXhwbGljaXRseSBkZWNpZGVkIG5vdCB0byBpbnRyb2R1Y2UgImhvdHAiIGFuZCAidG90cCIg aWRlbnRpZmllcnMgYmVjYXVzZSBubyBvbmUgaGFkIGEgdXNlIGNhc2UgaW4gd2hpY2ggdGhlIGRp c3RpbmN0aW9uIG1hdHRlcmVkLiAgT3RoZXJzIGNhbiBjZXJ0YWlubHkgaW50cm9kdWNlIHRob3Nl IGlkZW50aWZpZXJzIGFuZCByZWdpc3RlciB0aGVtIGlmIHRoZXkgZG8gaGF2ZSBzdWNoIGEgdXNl IGNhc2UsIG9uY2UgdGhlIHJlZ2lzdHJ5IGhhcyBiZWVuIGVzdGFibGlzaGVkLiAgQnV0IHRoZSB3 b3JraW5nIGdyb3VwIHdhbnRlZCB0byBiZSBjb25zZXJ2YXRpdmUgYWJvdXQgdGhlIGlkZW50aWZp ZXJzIGludHJvZHVjZWQgdG8gcHJpbWUgdGhlIHJlZ2lzdHJ5LCBhbmQgdGhpcyBpcyBzdWNoIGEg Y2FzZS4NCg0KV2hhdCBpZGVudGlmaWVycyB0byB1c2UgYW5kIHJlZ2lzdGVyIHdpbGwgYWx3YXlz IGJlIGEgYmFsYW5jaW5nIGFjdC4gIFlvdSB3YW50IHRvIGJlIGFzIHNwZWNpZmljIGFzIG5lY2Vz c2FyeSB0byBhZGQgcHJhY3RpY2FsIGFuZCB1c2FibGUgdmFsdWUsIGJ1dCBub3Qgc28gc3BlY2lm aWMgYXMgdG8gbWFrZSB0aGluZ3MgdW5uZWNlc3NhcmlseSBicml0dGxlLiAgV2hpbGUgc29tZSBt aWdodCBzYXkgdGhlcmUncyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBzZXJpYWwgbnVtYmVyIHJhbmdl cyBvZiBwYXJ0aWN1bGFyIGF1dGhlbnRpY2F0aW9uIGRldmljZXMsIGdvaW5nIHRoZXJlIGlzIGNs ZWFybHkgaW4gdGhlIHdlZWRzLiAgT24gdGhlIG90aGVyIGhhbmQsIHdoaWxlIHRoZXJlIHVzZWQg dG8gYmUgYW4gImV5ZSIgaWRlbnRpZmllciwgRWxhaW5lIE5ld3RvbiBvZiBOSVNUIHBvaW50ZWQg b3V0IHRoYXQgdGhlcmUgYXJlIHNpZ25pZmljYW50IGRpZmZlcmVuY2VzIGJldHdlZW4gcmV0aW5h IGFuZCBpcmlzIG1hdGNoaW5nLCBzbyAiZXllIiB3YXMgcmVwbGFjZWQgd2l0aCAicmV0aW5hIiBh bmQgImlyaXMiLiAgQ29tbW9uIHNlbnNlIGluZm9ybWVkIGJ5IGFjdHVhbCBkYXRhIGlzIHRoZSBr ZXkgaGVyZS4NCg0KVGhlIHBvaW50IG9mIHRoZSByZWdpc3RyeSByZXF1aXJpbmcgYSBzcGVjaWZp Y2F0aW9uIHJlZmVyZW5jZSBpcyBzbyBwZW9wbGUgdXNpbmcgdGhlIHJlZ2lzdHJ5IGNhbiB0ZWxs IHdoZXJlIHRoZSBpZGVudGlmaWVyIGlzIGRlZmluZWQuICBGb3IgYWxsIHRoZSBpbml0aWFsIHZh bHVlcywgdGhhdCByZXF1aXJlbWVudCBpcyBzYXRpc2ZpZWQsIHNpbmNlIHRoZSByZWZlcmVuY2Ug d2lsbCBiZSB0byB0aGUgbmV3IFJGQy4gIEkgdGhpbmsgdGhhdCBhbGlnbnMgd2l0aCB0aGUgcG9p bnQgdGhhdCBKb2VsIHdhcyBtYWtpbmcuDQoNCllvdXIgdGhvdWdodHM/DQoNCgkJCQktLSBNaWtl DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNClNlbnQ6IFdl ZG5lc2RheSwgRmVicnVhcnkgMSwgMjAxNyA3OjAzIEFNDQpUbzogam9lbCBqYWVnZ2xpIDxqb2Vs amFAYm9ndXMuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogb2F1dGgtY2hhaXJz QGlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7IG9hdXRoQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlcy0wNTogKHdpdGggRElTQ1VTUykNCg0KDQoN Ck9uIDAxLzAyLzE3IDE0OjU4LCBqb2VsIGphZWdnbGkgd3JvdGU6DQo+IE9uIDEvMzEvMTcgODoy NiBBTSwgU3RlcGhlbiBGYXJyZWxsIHdyb3RlOg0KPj4gU3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPj4gZHJhZnQtaWV0Zi1vYXV0 aC1hbXItdmFsdWVzLTA1OiBEaXNjdXNzDQo+Pg0KPj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Ug a2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsIA0KPj4gZW1haWwg YWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8g Y3V0IA0KPj4gdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4+DQo+Pg0K Pj4gUGxlYXNlIHJlZmVyIHRvIA0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQo+PiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPj4NCj4+DQo+PiBUaGUgZG9jdW1l bnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6 DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFt ci12YWx1ZXMvDQo+Pg0KPj4NCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+IERJU0NVU1M6 DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+DQo+PiBUaGlzIHNwZWNpZmljYXRpb24gc2VlbXMg dG8gbWUgdG8gYnJlYWsgaXQncyBvd24gcnVsZXMuIFlvdSBzdGF0ZSANCj4+IHRoYXQgcmVnaXN0 cmF0aW9ucyBzaG91bGQgaW5jbHVkZSBhIHJlZmVyZW5jZSB0byBhIHNwZWNpZmljYXRpb24gdG8g DQo+PiBpbXByb3ZlIGludGVyb3AuDQo+PiBBbmQgeWV0LCBmb3IgdGhlIHN0cmluZ3MgYWRkZWQg aGVyZSAoZS5nLiBvdHApIHlvdSBkb24ndCBkbyB0aGF0IA0KPj4gKHJlZmVycmluZyB0byBzZWN0 aW9uIDIgd2lsbCBub3QgaW1wcm92ZSBpbnRlcm9wKSBhbmQgdGhlcmUgYXJlIA0KPj4gZGlmZmVy ZW50IHdheXMgaW4gd2hpY2ggbWFueSBvZiB0aGUgbWV0aG9kcyBpbiBzZWN0aW9uIDIgY2FuIGJl IGRvbmUuDQo+PiBTbyBJIHRoaW5rIHlvdSBuZWVkIHRvIGFkZCBhIGJ1bmNoIG1vcmUgcmVmZXJl bmNlcy4NCj4gDQo+IE5vdCBjbGVhciB0byBtZSB0aGF0IHRoZSBkb2N1bWVudCBjcmVhdGluZyB0 aGUgcmVnaXN0cnkgbmVlZHMgdG8gDQo+IGFkaGVyZSB0byB0aGUgcnVsZXMgZm9yIGZ1cnRoZXIg YWxsb2NhdGlvbnMgaW4gb3JkZXIgdG8gcHJlcG91bGF0ZSB0aGUgDQo+IHJlZ2lzdHJ5LiB0aGF0 IGlzIHBlcmhhcHMgYW4gYXBwZWFsIHRvIGZ1dHVyZSBjb25zaXN0ZW5jeS4NCg0KU3VyZSAtIEkn bSBhbGwgZm9yIGEgc21hdHRlcmluZyBvZiBpbmNvbnNpc3RlbmN5Oi0pDQoNCkJ1dCBJIHRoaW5r IHRoZSBsYWNrIG9mIHNwZWNzIGluIHNvbWUgb2YgdGhlc2UgY2FzZXMgY291bGQgaW1wYWN0IG9u IGludGVyb3AsIGUuZy4gaW4gdGhlIG90cCBjYXNlLCB0aGV5IHF1b3RlIHR3byBSRkNzIGFuZCB5 ZXQgb25seSBoYXZlIG9uZSB2YWx1ZS4gVGhhdCBzZWVtcyBhIGJpdCBicm9rZW4gdG8gbWUsIHNv IHRoZSBkaXNjdXNzIGlzbid0IHJlYWxseSBhYm91dCB0aGUgZm9ybWFsaXNtLg0KDQpTLg0KDQoN Cj4+DQo+Pg0KPj4NCj4gDQo+IA0KDQo= From nobody Wed Feb 1 14:26:01 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871DA1295C6; Wed, 1 Feb 2017 14:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l5F_DuWB_4k; Wed, 1 Feb 2017 14:25:53 -0800 (PST) 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 CCB181294A5; Wed, 1 Feb 2017 14:25:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 27535BE5B; Wed, 1 Feb 2017 22:25:50 +0000 (GMT) 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 isxMEEWYnTO0; Wed, 1 Feb 2017 22:25:48 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B8784BE58; Wed, 1 Feb 2017 22:25:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485987948; bh=U00HrQZ66ZR/1sf/BWMSJQCIWsn1cpb8kggb4OJWRtE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=eiuZzBHopT215K/CHa2a6O7DYAxKka45N8T9uArjX8D4j2QtWxlw33Bi6DjDL50wh DgpMsJMnAQVjWodKQbCgJ8ZoVcd4WgZxpTmbLgqnwYM6yLOcpGGLzwigQR2DlJ/CYh przmvt0epRF+ct4YbHHVQT0oYaChlxBPDLJhYGcs= To: Mike Jones , joel jaeggli , The IESG References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> Date: Wed, 1 Feb 2017 22:25:47 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040900000301060103060202" Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 22:25:55 -0000 This is a cryptographically signed message in MIME format. --------------ms040900000301060103060202 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mike, On 01/02/17 17:00, Mike Jones wrote: > Thanks for the discussion, Stephen. >=20 > To your point about "otp", the working group discussed this very > point. They explicitly decided not to introduce "hotp" and "totp" > identifiers because no one had a use case in which the distinction > mattered. =20 Then I'm not following why adding "otp" to the registry now is a good plan. If there's a use-case now, then adding an entry with a good reference to the relevant spec seems right. If there's no use-case now, then not adding it to the registry seems right. (Mentioning it as a possible future entry would be fine.) I think the same logic would apply for all the values that this spec adds to the registry. Why is that wrong? > Others can certainly introduce those identifiers and > register them if they do have such a use case, once the registry has > been established. But the working group wanted to be conservative > about the identifiers introduced to prime the registry, and this is > such a case. >=20 > What identifiers to use and register will always be a balancing act. > You want to be as specific as necessary to add practical and usable > value, but not so specific as to make things unnecessarily brittle. Eh... don't we want interop? Isn't that the primary goal here? > While some might say there's a difference between serial number > ranges of particular authentication devices, going there is clearly > in the weeds. On the other hand, while there used to be an "eye" > identifier, Elaine Newton of NIST pointed out that there are > significant differences between retina and iris matching, so "eye" > was replaced with "retina" and "iris". Common sense informed by > actual data is the key here. That's another good example. There's no reference for "iris." If that is used in some protocol, then what format(s) are expected to be supported? Where do I find that spec? If we can answer that, then great, let's add the details. If not, then I'd suggest we omit "iris" and leave it 'till later to add an entry for that. And again, including text with "iris" as an example is just fine, all I'm asking is that we only add the registry entry if we can meet the same bar that we're asking the DE to impose on later additions. And the same for all the others... Cheers, S. >=20 > The point of the registry requiring a specification reference is so > people using the registry can tell where the identifier is defined. > For all the initial values, that requirement is satisfied, since the > reference will be to the new RFC. I think that aligns with the point > that Joel was making. >=20 > Your thoughts? >=20 > -- Mike >=20 > -----Original Message----- From: OAuth > [mailto:oauth-bounces@ietf.org] On Behalf Of Stephen Farrell Sent: > Wednesday, February 1, 2017 7:03 AM To: joel jaeggli > ; The IESG Cc: > oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org; > oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) >=20 >=20 >=20 > On 01/02/17 14:58, joel jaeggli wrote: >> On 1/31/17 8:26 AM, Stephen Farrell wrote: >>> Stephen Farrell has entered the following ballot position for=20 >>> draft-ietf-oauth-amr-values-05: Discuss >>>=20 >>> 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.) >>>=20 >>>=20 >>> Please refer to=20 >>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>> more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found >>> here:=20 >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ >>>=20 >>>=20 >>>=20 >>> ---------------------------------------------------------------------= >>> >>>=20 - >>> DISCUSS:=20 >>> ---------------------------------------------------------------------= >>> >>>=20 - >>>=20 >>> This specification seems to me to break it's own rules. You state >>> that registrations should include a reference to a specification >>> to improve interop. And yet, for the strings added here (e.g. >>> otp) you don't do that (referring to section 2 will not improve >>> interop) and there are different ways in which many of the >>> methods in section 2 can be done. So I think you need to add a >>> bunch more references. >>=20 >> Not clear to me that the document creating the registry needs to=20 >> adhere to the rules for further allocations in order to prepoulate >> the registry. that is perhaps an appeal to future consistency. >=20 > Sure - I'm all for a smattering of inconsistency:-) >=20 > But I think the lack of specs in some of these cases could impact on > interop, e.g. in the otp case, they quote two RFCs and yet only have > one value. That seems a bit broken to me, so the discuss isn't really > about the formalism. >=20 > S. >=20 >=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 --------------ms040900000301060103060202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDEy MjI1NDdaMC8GCSqGSIb3DQEJBDEiBCD/LPUQ1E8l19S+wxvmL8X1sWlzEfoYWLIp5f6vuAGS wTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBCt4q3hC4p8qk7XoyVyeuyhMiS/v/BnmnD4Kto33gY0ylSESY80C9p tJ6QDfaipnIN5/bPdK//xvS4XGTDKaiaToTyceb/KngQoHIFmHJCNkzsT9vi87Wx/y9vi59Z i3B2NAGAmsTYiJKnWfP6QWSVrwxdEQ/glavjd71YNmIQTIvQfI2MnV7GshK5zcJDQiHBuqty Rw2iPs9GT2cE5im9dubr8O1evf9OFr+tuPN6NeTYJrBaa8bkYUiw2wpD6OOkAIKxbI/uQtZO +ITAfe+McHH8J25Sp2upzlGe5ESYE87N7Lk+NsPU4lkh6rijw+TQdj5FI70XHJXiyIlcev+J AAAAAAAA --------------ms040900000301060103060202-- From nobody Wed Feb 1 15:48:34 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C2F12961B; Wed, 1 Feb 2017 15:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6enMvjpA6fxu; Wed, 1 Feb 2017 15:48:31 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 DB698129627; Wed, 1 Feb 2017 15:48:30 -0800 (PST) X-AuditID: 1209190f-03bff70000000b40-b1-589273ccc9a4 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 (Symantec Messaging Gateway) with SMTP id A1.9E.02880.CC372985; Wed, 1 Feb 2017 18:48:29 -0500 (EST) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v11NmS1N026775; Wed, 1 Feb 2017 18:48:28 -0500 Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (w92exedge6.exchange.mit.edu [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id v11NmRPX020010; Wed, 1 Feb 2017 18:48:27 -0500 Received: from W92EXCAS23.exchange.mit.edu (18.7.71.38) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 1 Feb 2017 18:48:14 -0500 Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.80]) by w92excas23.exchange.mit.edu ([18.7.71.38]) with mapi id 14.03.0339.000; Wed, 1 Feb 2017 18:48:26 -0500 From: Thomas Hardjono To: "oauth@ietf.org" , "oauth-chairs@ietf.org" Thread-Topic: Decentralized OAuth2.0 -- FW: New Version Notification for draft-hardjono-oauth-decentralized-00.txt Thread-Index: AQHSfOVlyUPOs0QsG0eqL+eCJmsJww== Date: Wed, 1 Feb 2017 23:48:26 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342AC1CD7488@OC11EXPO33.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.48.116.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUixCmqrXu2eFKEwdxmc4vbc1eyWZx8+4rN gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZt7ZcZyt4xl/Rvf8cewPjZZ4uRk4OCQETieedE9m7 GLk4hATamCTmXpgL5exnlPh/9S0zhHOUUWJZ1xOozDZGiWPH90A5Kxklnh58zAQyjE1AQ6Lt Ry87iC0ikChxbeFpFhBbWCBf4tesK2wQ8RKJ1Yu/Qdl6Ei/erWYEsVkEVCQW7TkCNodXIEii ecNRsBpGATGJ76fWgMWZBcQlbj2ZzwRxuKDEotl7mCFsMYl/ux6yQdgKEosvXWeDqNeRWLD7 E5StLbFs4WtmiPmCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG2ZTcKt3cxMyc4tRk3eLk xLy81CJdE73czBK91JTSTYzgqJHk38E4p8H7EKMAB6MSD2+G2KQIIdbEsuLK3EOMkhxMSqK8 XoFAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8nYVAOd6UxMqq1KJ8mJQ0B4uSOK+4RmOEkEB6 YklqdmpqQWoRTFaGg0NJgvd+EVCjYFFqempFWmZOCUKaiYMTZDgP0HDnYpDhxQWJucWZ6RD5 U4yKUuK8z0CaBUASGaV5cL3gpMbuKfOKURzoFWHeFyBVPMCECNf9CmgwE9Bg91d9IINLEhFS Ug2MCzVnZ3hfV3r6/+sxk50OlmsTtHt8V/y72/OLTauMr3rPdiFZVullh9MWh/M/yVcoXvtY aJMPY0JcRUtbWKmyb+ZaxjbB0mM27WJfbD1W6TA9P7TDuO28Vwa/AvPROznGN/al9uyb56WT ycy19v6dv1vUuoNmpXIUrdsj/3GG4slkAceNa44qsRRnJBpqMRcVJwIAQLuNPUUDAAA= Archived-At: Subject: [OAUTH-WG] Decentralized OAuth2.0 -- FW: New Version Notification for draft-hardjono-oauth-decentralized-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 23:48:32 -0000 Folks, This may be of interest. Its forward-looking, I know. Appreciate any commen= ts on the draft. Best. /thomas/ ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Wednesday, February 01, 2017 6:39 PM To: Thomas Hardjono Subject: New Version Notification for draft-hardjono-oauth-decentralized-00= .txt A new version of I-D, draft-hardjono-oauth-decentralized-00.txt has been successfully submitted by Thomas Hardjono and posted to the IETF repository. Name: draft-hardjono-oauth-decentralized Revision: 00 Title: Decentralized Service Architecture for OAuth2.0 Document date: 2017-02-01 Group: Individual Submission Pages: 21 URL: https://www.ietf.org/internet-drafts/draft-hardjono-oauth-d= ecentralized-00.txt Status: https://datatracker.ietf.org/doc/draft-hardjono-oauth-decen= tralized/ Htmlized: https://tools.ietf.org/html/draft-hardjono-oauth-decentrali= zed-00 Abstract: This document proposes an alternative service architecture for user- centric control of the sharing of resources, such as personal data, using the decentralized peer-to-peer computing paradigm. The term 'control' is used here to denote the full capacity of the user to freely select (i) the entities with whom to share resources (e.g. data), and (ii) the entities which provide services implementing user-controlled resource sharing. The peer-to-peer service architecture uses a set of computing nodes called OAuth2.0 Nodes (ON) that are part of a peer-to-peer network as the basis for the decentralized service architecture. Each OAuth2.0 Nodes is assumed to have the capability to provide AS-services, RS-services and Client-services. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Feb 1 16:10:30 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78362129612; Wed, 1 Feb 2017 16:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaqslA82lu3z; Wed, 1 Feb 2017 16:10:25 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0105.outbound.protection.outlook.com [104.47.36.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F11129577; Wed, 1 Feb 2017 16:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GKXgKsKoNMBW4ycAE2e/n1w2wxO0bhMmED4i0+5S3n4=; b=gFuc10WCgu7TLSXxNd9aiCC45/kIVC6IO2ZwCDgv4shkZ5hYUZXFJN7O+JwUZO33Kqs2LfBthfRtU6rp3Wpn549KUgY714RXvOnJKnIPBmyBM05l0NcLQx3NKoUnVrTg8LwfYLeO/kV1onaFW8uBSe9W+lcIq/dytqb+TX8uWs4= Received: from SN1PR0301MB2029.namprd03.prod.outlook.com (10.163.226.27) by SN2PR03MB2365.namprd03.prod.outlook.com (10.166.210.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 00:10:22 +0000 Received: from SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) by SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) with mapi id 15.01.0860.026; Thu, 2 Feb 2017 00:10:22 +0000 From: Anthony Nadalin To: Stephen Farrell , Mike Jones , joel jaeggli , The IESG Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) Thread-Index: AQHSe97GorBcOHuDmkGNgYGkSGkYdqFUP6sAgAABIQCAACDtgIAAWs6AgAAcifA= Date: Thu, 2 Feb 2017 00:10:22 +0000 Message-ID: References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> In-Reply-To: <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [131.107.159.71] x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-ms-office365-filtering-correlation-id: 48231abd-5fbb-401a-c0a9-08d44affe15e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN2PR03MB2365; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2365; 7:b8qXWHLx9ZTRzYTwzAq4iw49o+TJJNshikfHV8YwuHxFwAV0LN+f+SndzBLHp8NZ84TLFQpcIHBGs/fOOtz+wSxXFPGbLV9UifUT8OLTsnbFeX+bblz4rCmwaSiOYLLcCXUC+2QMmk7ewZQ3xXNySTqhh9VR4LgwRNeES9qXivqVLwmziEiuh2HiRBpzfLYlLdfoqac5/SsgR7MBSzmF5ZsZkpbyXo/cwgxafzODnk7lOJyec1H4HBNNTJKqjnrGQ5WEnotWk3B/orkBRPcHShk3ectn4CRLaAmXrQZFj1ea2DNzvy/jvFoGyGNwUIOSTdq9GASLqJAZy4PSPKB9JC/CZRh9o1gkOsbrU2UJubKV73VZb3AnRULxR70KmI+JDyhEkPXMXyhP7rf9DlBrD28pByRqa9C4Cep9boMYTGitff6E+Me9wh639Sn32K9JwnHuNMCNiHW8ewSFVvHM234rZ8SumJpflQ4UN7fUDLx509bvsXa5kpUemnobDbqu0NqlnLutPnshj2T+1Cx0WIo28sSFdaegWkjymH2UBywVl/p+JiR4r5WmSr1KN8ey x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(20161123558025)(6072148); SRVR:SN2PR03MB2365; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2365; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39850400002)(39410400002)(39840400002)(39450400003)(40224003)(51914003)(13464003)(377454003)(189002)(51444003)(24454002)(199003)(2561002)(92566002)(3846002)(305945005)(102836003)(6116002)(99286003)(54906002)(53936002)(74316002)(3660700001)(5660300001)(2900100001)(966004)(230783001)(86362001)(4326007)(8990500004)(3280700002)(7736002)(2906002)(86612001)(68736007)(5005710100001)(7696004)(76176999)(122556002)(93886004)(6436002)(66066001)(97736004)(101416001)(2421001)(10290500002)(189998001)(33656002)(50986999)(54356999)(106356001)(9686003)(81156014)(81166006)(106116001)(55016002)(10090500001)(6306002)(1511001)(8676002)(8936002)(229853002)(2950100002)(38730400001)(77096006)(25786008)(6506006)(5001770100001)(105586002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR03MB2365; H:SN1PR0301MB2029.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 00:10:22.2259 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2365 Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:10:29 -0000 TklTVCBhc2tlZCBmb3IgdGhlIGFkZGl0aW9uIG9mIElSSVMgKGFzIHRoZXkgYXJlIHNlZWluZyBt b3JlIHVzZSBvZiBJUklTIG92ZXIgcmV0aW5hIGR1ZSB0byB0aGUgYWNjdXJhY3kgb2YgaXJpcykg IGFzIHRoZXkgaGF2ZSBiZWVuIGRvaW5nIHNpZ25pZmljYW50IHRlc3Rpbmcgb24gdmFyaW91cyBp cmlzIGRldmljZXMgYW5kIGNvbnRpbnVlIHRvIGRvIHNvLCBoZXJlIGlzIGEgcmVwb3J0IHRoYXQg TklTVCByZWxlYXNlZCBodHRwOi8vMjAxMC0yMDE0LmNvbW1lcmNlLmdvdi9ibG9nLzIwMTIvMDQv MjMvbmlzdC1pcmlzLXJlY29nbml0aW9uLXJlcG9ydC1ldmFsdWF0ZXMtbmVlZGxlLWhheXN0YWNr LXNlYXJjaC1jYXBhYmlsaXR5Lmh0bWwgIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0g DQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEsIDIwMTcgMjoyNiBQTQ0KVG86IE1pa2UgSm9u ZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IGpvZWwgamFlZ2dsaSA8am9lbGphQGJv Z3VzLmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IG9hdXRoLWNoYWlyc0BpZXRm Lm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzQGlldGYub3JnOyBvYXV0aEBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6ICh3aXRoIERJU0NVU1MpDQoNCg0KSGkgTWlr ZSwNCg0KT24gMDEvMDIvMTcgMTc6MDAsIE1pa2UgSm9uZXMgd3JvdGU6DQo+IFRoYW5rcyBmb3Ig dGhlIGRpc2N1c3Npb24sIFN0ZXBoZW4uDQo+IA0KPiBUbyB5b3VyIHBvaW50IGFib3V0ICJvdHAi LCB0aGUgd29ya2luZyBncm91cCBkaXNjdXNzZWQgdGhpcyB2ZXJ5DQo+IHBvaW50LiAgVGhleSBl eHBsaWNpdGx5IGRlY2lkZWQgbm90IHRvIGludHJvZHVjZSAiaG90cCIgYW5kICJ0b3RwIg0KPiBp ZGVudGlmaWVycyBiZWNhdXNlIG5vIG9uZSBoYWQgYSB1c2UgY2FzZSBpbiB3aGljaCB0aGUgZGlz dGluY3Rpb24NCj4gbWF0dGVyZWQuICANCg0KVGhlbiBJJ20gbm90IGZvbGxvd2luZyB3aHkgYWRk aW5nICJvdHAiIHRvIHRoZSByZWdpc3RyeSBub3cNCmlzIGEgZ29vZCBwbGFuLg0KDQpJZiB0aGVy ZSdzIGEgdXNlLWNhc2Ugbm93LCB0aGVuIGFkZGluZyBhbiBlbnRyeSB3aXRoIGEgZ29vZA0KcmVm ZXJlbmNlIHRvIHRoZSByZWxldmFudCBzcGVjIHNlZW1zIHJpZ2h0Lg0KDQpJZiB0aGVyZSdzIG5v IHVzZS1jYXNlIG5vdywgdGhlbiBub3QgYWRkaW5nIGl0IHRvIHRoZQ0KcmVnaXN0cnkgc2VlbXMg cmlnaHQuIChNZW50aW9uaW5nIGl0IGFzIGEgcG9zc2libGUgZnV0dXJlDQplbnRyeSB3b3VsZCBi ZSBmaW5lLikNCg0KSSB0aGluayB0aGUgc2FtZSBsb2dpYyB3b3VsZCBhcHBseSBmb3IgYWxsIHRo ZSB2YWx1ZXMgdGhhdA0KdGhpcyBzcGVjIGFkZHMgdG8gdGhlIHJlZ2lzdHJ5LiBXaHkgaXMgdGhh dCB3cm9uZz8NCg0KPiBPdGhlcnMgY2FuIGNlcnRhaW5seSBpbnRyb2R1Y2UgdGhvc2UgaWRlbnRp ZmllcnMgYW5kDQo+IHJlZ2lzdGVyIHRoZW0gaWYgdGhleSBkbyBoYXZlIHN1Y2ggYSB1c2UgY2Fz ZSwgb25jZSB0aGUgcmVnaXN0cnkgaGFzDQo+IGJlZW4gZXN0YWJsaXNoZWQuICBCdXQgdGhlIHdv cmtpbmcgZ3JvdXAgd2FudGVkIHRvIGJlIGNvbnNlcnZhdGl2ZQ0KPiBhYm91dCB0aGUgaWRlbnRp ZmllcnMgaW50cm9kdWNlZCB0byBwcmltZSB0aGUgcmVnaXN0cnksIGFuZCB0aGlzIGlzDQo+IHN1 Y2ggYSBjYXNlLg0KPiANCj4gV2hhdCBpZGVudGlmaWVycyB0byB1c2UgYW5kIHJlZ2lzdGVyIHdp bGwgYWx3YXlzIGJlIGEgYmFsYW5jaW5nIGFjdC4NCj4gWW91IHdhbnQgdG8gYmUgYXMgc3BlY2lm aWMgYXMgbmVjZXNzYXJ5IHRvIGFkZCBwcmFjdGljYWwgYW5kIHVzYWJsZQ0KPiB2YWx1ZSwgYnV0 IG5vdCBzbyBzcGVjaWZpYyBhcyB0byBtYWtlIHRoaW5ncyB1bm5lY2Vzc2FyaWx5IGJyaXR0bGUu DQoNCkVoLi4uIGRvbid0IHdlIHdhbnQgaW50ZXJvcD8gSXNuJ3QgdGhhdCB0aGUgcHJpbWFyeSBn b2FsIGhlcmU/DQoNCj4gV2hpbGUgc29tZSBtaWdodCBzYXkgdGhlcmUncyBhIGRpZmZlcmVuY2Ug YmV0d2VlbiBzZXJpYWwgbnVtYmVyDQo+IHJhbmdlcyBvZiBwYXJ0aWN1bGFyIGF1dGhlbnRpY2F0 aW9uIGRldmljZXMsIGdvaW5nIHRoZXJlIGlzIGNsZWFybHkNCj4gaW4gdGhlIHdlZWRzLiAgT24g dGhlIG90aGVyIGhhbmQsIHdoaWxlIHRoZXJlIHVzZWQgdG8gYmUgYW4gImV5ZSINCj4gaWRlbnRp ZmllciwgRWxhaW5lIE5ld3RvbiBvZiBOSVNUIHBvaW50ZWQgb3V0IHRoYXQgdGhlcmUgYXJlDQo+ IHNpZ25pZmljYW50IGRpZmZlcmVuY2VzIGJldHdlZW4gcmV0aW5hIGFuZCBpcmlzIG1hdGNoaW5n LCBzbyAiZXllIg0KPiB3YXMgcmVwbGFjZWQgd2l0aCAicmV0aW5hIiBhbmQgImlyaXMiLiAgQ29t bW9uIHNlbnNlIGluZm9ybWVkIGJ5DQo+IGFjdHVhbCBkYXRhIGlzIHRoZSBrZXkgaGVyZS4NCg0K VGhhdCdzIGFub3RoZXIgZ29vZCBleGFtcGxlLiBUaGVyZSdzIG5vIHJlZmVyZW5jZSBmb3IgImly aXMuIiBJZg0KdGhhdCBpcyB1c2VkIGluIHNvbWUgcHJvdG9jb2wsIHRoZW4gd2hhdCBmb3JtYXQo cykgYXJlIGV4cGVjdGVkDQp0byBiZSBzdXBwb3J0ZWQ/IFdoZXJlIGRvIEkgZmluZCB0aGF0IHNw ZWM/IElmIHdlIGNhbiBhbnN3ZXIgdGhhdCwNCnRoZW4gZ3JlYXQsIGxldCdzIGFkZCB0aGUgZGV0 YWlscy4gSWYgbm90LCB0aGVuIEknZCBzdWdnZXN0IHdlDQpvbWl0ICJpcmlzIiBhbmQgbGVhdmUg aXQgJ3RpbGwgbGF0ZXIgdG8gYWRkIGFuIGVudHJ5IGZvciB0aGF0Lg0KQW5kIGFnYWluLCBpbmNs dWRpbmcgdGV4dCB3aXRoICJpcmlzIiBhcyBhbiBleGFtcGxlIGlzIGp1c3QgZmluZSwNCmFsbCBJ J20gYXNraW5nIGlzIHRoYXQgd2Ugb25seSBhZGQgdGhlIHJlZ2lzdHJ5IGVudHJ5IGlmIHdlIGNh bg0KbWVldCB0aGUgc2FtZSBiYXIgdGhhdCB3ZSdyZSBhc2tpbmcgdGhlIERFIHRvIGltcG9zZSBv biBsYXRlcg0KYWRkaXRpb25zLg0KDQpBbmQgdGhlIHNhbWUgZm9yIGFsbCB0aGUgb3RoZXJzLi4u DQoNCkNoZWVycywNClMuDQoNCg0KPiANCj4gVGhlIHBvaW50IG9mIHRoZSByZWdpc3RyeSByZXF1 aXJpbmcgYSBzcGVjaWZpY2F0aW9uIHJlZmVyZW5jZSBpcyBzbw0KPiBwZW9wbGUgdXNpbmcgdGhl IHJlZ2lzdHJ5IGNhbiB0ZWxsIHdoZXJlIHRoZSBpZGVudGlmaWVyIGlzIGRlZmluZWQuDQo+IEZv ciBhbGwgdGhlIGluaXRpYWwgdmFsdWVzLCB0aGF0IHJlcXVpcmVtZW50IGlzIHNhdGlzZmllZCwg c2luY2UgdGhlDQo+IHJlZmVyZW5jZSB3aWxsIGJlIHRvIHRoZSBuZXcgUkZDLiAgSSB0aGluayB0 aGF0IGFsaWducyB3aXRoIHRoZSBwb2ludA0KPiB0aGF0IEpvZWwgd2FzIG1ha2luZy4NCj4gDQo+ IFlvdXIgdGhvdWdodHM/DQo+IA0KPiAtLSBNaWtlDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLSBGcm9tOiBPQXV0aA0KPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwgU2VudDoNCj4gV2VkbmVzZGF5LCBGZWJydWFyeSAx LCAyMDE3IDc6MDMgQU0gVG86IGpvZWwgamFlZ2dsaQ0KPiA8am9lbGphQGJvZ3VzLmNvbT47IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPiBDYzoNCj4gb2F1dGgtY2hhaXJzQGlldGYub3JnOyBkcmFm dC1pZXRmLW9hdXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7DQo+IG9hdXRoQGlldGYub3JnIFN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mgb24NCj4gZHJhZnQt aWV0Zi1vYXV0aC1hbXItdmFsdWVzLTA1OiAod2l0aCBESVNDVVNTKQ0KPiANCj4gDQo+IA0KPiBP biAwMS8wMi8xNyAxNDo1OCwgam9lbCBqYWVnZ2xpIHdyb3RlOg0KPj4gT24gMS8zMS8xNyA4OjI2 IEFNLCBTdGVwaGVuIEZhcnJlbGwgd3JvdGU6DQo+Pj4gU3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvciANCj4+PiBkcmFmdC1pZXRmLW9h dXRoLWFtci12YWx1ZXMtMDU6IERpc2N1c3MNCj4+PiANCj4+PiBXaGVuIHJlc3BvbmRpbmcsIHBs ZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0bw0KPj4+IGFsbCBl bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZQ0KPj4+IHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPj4+ IA0KPj4+IA0KPj4+IFBsZWFzZSByZWZlciB0byANCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9p ZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwgZm9yDQo+Pj4gbW9yZSBpbmZvcm1h dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPj4+IA0KPj4+ IA0KPj4+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBj YW4gYmUgZm91bmQNCj4+PiBoZXJlOiANCj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMvDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+Pj4NCj4+PiANCi0NCj4+PiBESVNDVVNTOiANCj4+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+Pg0KPj4+IA0KLQ0KPj4+IA0KPj4+IFRoaXMgc3BlY2lmaWNhdGlvbiBzZWVtcyB0byBt ZSB0byBicmVhayBpdCdzIG93biBydWxlcy4gWW91IHN0YXRlDQo+Pj4gIHRoYXQgcmVnaXN0cmF0 aW9ucyBzaG91bGQgaW5jbHVkZSBhIHJlZmVyZW5jZSB0byBhIHNwZWNpZmljYXRpb24NCj4+PiB0 byBpbXByb3ZlIGludGVyb3AuIEFuZCB5ZXQsIGZvciB0aGUgc3RyaW5ncyBhZGRlZCBoZXJlIChl LmcuDQo+Pj4gb3RwKSB5b3UgZG9uJ3QgZG8gdGhhdCAocmVmZXJyaW5nIHRvIHNlY3Rpb24gMiB3 aWxsIG5vdCBpbXByb3ZlDQo+Pj4gaW50ZXJvcCkgYW5kIHRoZXJlIGFyZSBkaWZmZXJlbnQgd2F5 cyBpbiB3aGljaCBtYW55IG9mIHRoZQ0KPj4+IG1ldGhvZHMgaW4gc2VjdGlvbiAyIGNhbiBiZSBk b25lLiBTbyBJIHRoaW5rIHlvdSBuZWVkIHRvIGFkZCBhDQo+Pj4gYnVuY2ggbW9yZSByZWZlcmVu Y2VzLg0KPj4gDQo+PiBOb3QgY2xlYXIgdG8gbWUgdGhhdCB0aGUgZG9jdW1lbnQgY3JlYXRpbmcg dGhlIHJlZ2lzdHJ5IG5lZWRzIHRvIA0KPj4gYWRoZXJlIHRvIHRoZSBydWxlcyBmb3IgZnVydGhl ciBhbGxvY2F0aW9ucyBpbiBvcmRlciB0byBwcmVwb3VsYXRlDQo+PiB0aGUgcmVnaXN0cnkuIHRo YXQgaXMgcGVyaGFwcyBhbiBhcHBlYWwgdG8gZnV0dXJlIGNvbnNpc3RlbmN5Lg0KPiANCj4gU3Vy ZSAtIEknbSBhbGwgZm9yIGEgc21hdHRlcmluZyBvZiBpbmNvbnNpc3RlbmN5Oi0pDQo+IA0KPiBC dXQgSSB0aGluayB0aGUgbGFjayBvZiBzcGVjcyBpbiBzb21lIG9mIHRoZXNlIGNhc2VzIGNvdWxk IGltcGFjdCBvbg0KPiBpbnRlcm9wLCBlLmcuIGluIHRoZSBvdHAgY2FzZSwgdGhleSBxdW90ZSB0 d28gUkZDcyBhbmQgeWV0IG9ubHkgaGF2ZQ0KPiBvbmUgdmFsdWUuIFRoYXQgc2VlbXMgYSBiaXQg YnJva2VuIHRvIG1lLCBzbyB0aGUgZGlzY3VzcyBpc24ndCByZWFsbHkNCj4gYWJvdXQgdGhlIGZv cm1hbGlzbS4NCj4gDQo+IFMuDQo+IA0KPiANCj4+PiANCj4+PiANCj4+PiANCj4+IA0KPj4gDQo+ IA0KDQo= From nobody Wed Feb 1 16:15:11 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A0F129625; Wed, 1 Feb 2017 16:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmPdEthTM5A1; Wed, 1 Feb 2017 16:15:02 -0800 (PST) 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 5EFD112961B; Wed, 1 Feb 2017 16:15:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BAF98BE3E; Thu, 2 Feb 2017 00:14:59 +0000 (GMT) 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 EvljAo7-rJaZ; Thu, 2 Feb 2017 00:14:57 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E473FBE5B; Thu, 2 Feb 2017 00:14:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485994497; bh=oLZwbg//9x9X0lwHKiELarPCIqE05e5x5X75DQ8JiaU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=VoIA3ZvygVqODWxyECNmltcbIKoXMj1UrRAaLOaz5UVihk1loqZjHjlrSwC6e4/4S gFlixu3NoxdBChn9zZrA8HyK+79BgHdrh+a6FhNVefZ5dQrEqBNiElzI2tp8ksC2xK V4jxiEHj0O1lI43k49nRMZzc1c5KogmO/Xb5rjk0= To: Anthony Nadalin , Mike Jones , joel jaeggli , The IESG References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2dbfc379-7926-5794-22e8-1f09618ae5ea@cs.tcd.ie> Date: Thu, 2 Feb 2017 00:14:56 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090500000001010801070607" Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:15:05 -0000 This is a cryptographically signed message in MIME format. --------------ms090500000001010801070607 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tony, On 02/02/17 00:10, Anthony Nadalin wrote: > NIST asked for the addition of IRIS (as they are seeing more use of > IRIS over retina due to the accuracy of iris) as they have been > doing significant testing on various iris devices and continue to do > so, here is a report that NIST released > http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-rep= ort-evaluates-needle-haystack-search-capability.html >=20 Sorry, but that doesn't help me (at first glance anyway). If there's a reference that'd garner us interop, then great, just add it to match the codepoint. If there's not, I don't see why adding a codepoint is useful. (Esp. if we're at the stage of testing "various iris devices" that I would guess do not get us interop.) Am I missing something? Cheers, S. >=20 > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, February 1, 2017 > 2:26 PM To: Mike Jones ; joel jaeggli > ; The IESG Cc: > oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org; > oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) >=20 >=20 > Hi Mike, >=20 > On 01/02/17 17:00, Mike Jones wrote: >> Thanks for the discussion, Stephen. >>=20 >> To your point about "otp", the working group discussed this very=20 >> point. They explicitly decided not to introduce "hotp" and "totp"=20 >> identifiers because no one had a use case in which the distinction=20 >> mattered. >=20 > Then I'm not following why adding "otp" to the registry now is a good > plan. >=20 > If there's a use-case now, then adding an entry with a good reference > to the relevant spec seems right. >=20 > If there's no use-case now, then not adding it to the registry seems > right. (Mentioning it as a possible future entry would be fine.) >=20 > I think the same logic would apply for all the values that this spec > adds to the registry. Why is that wrong? >=20 >> Others can certainly introduce those identifiers and register them >> if they do have such a use case, once the registry has been >> established. But the working group wanted to be conservative about >> the identifiers introduced to prime the registry, and this is such >> a case. >>=20 >> What identifiers to use and register will always be a balancing >> act. You want to be as specific as necessary to add practical and >> usable value, but not so specific as to make things unnecessarily >> brittle. >=20 > Eh... don't we want interop? Isn't that the primary goal here? >=20 >> While some might say there's a difference between serial number=20 >> ranges of particular authentication devices, going there is >> clearly in the weeds. On the other hand, while there used to be an >> "eye" identifier, Elaine Newton of NIST pointed out that there are=20 >> significant differences between retina and iris matching, so "eye"=20 >> was replaced with "retina" and "iris". Common sense informed by=20 >> actual data is the key here. >=20 > That's another good example. There's no reference for "iris." If that > is used in some protocol, then what format(s) are expected to be > supported? Where do I find that spec? If we can answer that, then > great, let's add the details. If not, then I'd suggest we omit "iris" > and leave it 'till later to add an entry for that. And again, > including text with "iris" as an example is just fine, all I'm asking > is that we only add the registry entry if we can meet the same bar > that we're asking the DE to impose on later additions. >=20 > And the same for all the others... >=20 > Cheers, S. >=20 >=20 >>=20 >> The point of the registry requiring a specification reference is >> so people using the registry can tell where the identifier is >> defined. For all the initial values, that requirement is satisfied, >> since the reference will be to the new RFC. I think that aligns >> with the point that Joel was making. >>=20 >> Your thoughts? >>=20 >> -- Mike >>=20 >> -----Original Message----- From: OAuth=20 >> [mailto:oauth-bounces@ietf.org] On Behalf Of Stephen Farrell Sent:=20 >> Wednesday, February 1, 2017 7:03 AM To: joel jaeggli=20 >> ; The IESG Cc:=20 >> oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org;=20 >> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss >> on draft-ietf-oauth-amr-values-05: (with DISCUSS) >>=20 >>=20 >>=20 >> On 01/02/17 14:58, joel jaeggli wrote: >>> On 1/31/17 8:26 AM, Stephen Farrell wrote: >>>> Stephen Farrell has entered the following ballot position for=20 >>>> draft-ietf-oauth-amr-values-05: Discuss >>>>=20 >>>> 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.) >>>>=20 >>>>=20 >>>> Please refer to=20 >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for=20 >>>> more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found=20 >>>> here:=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ >>>>=20 >>>>=20 >>>>=20 >>>> --------------------------------------------------------------------= - >>>> >>>> > >>>>=20 - >>>> DISCUSS:=20 >>>> --------------------------------------------------------------------= - >>>> >>>> > >>>>=20 - >>>>=20 >>>> This specification seems to me to break it's own rules. You >>>> state that registrations should include a reference to a >>>> specification to improve interop. And yet, for the strings >>>> added here (e.g. otp) you don't do that (referring to section 2 >>>> will not improve interop) and there are different ways in which >>>> many of the methods in section 2 can be done. So I think you >>>> need to add a bunch more references. >>>=20 >>> Not clear to me that the document creating the registry needs to >>> adhere to the rules for further allocations in order to >>> prepoulate the registry. that is perhaps an appeal to future >>> consistency. >>=20 >> Sure - I'm all for a smattering of inconsistency:-) >>=20 >> But I think the lack of specs in some of these cases could impact >> on interop, e.g. in the otp case, they quote two RFCs and yet only >> have one value. That seems a bit broken to me, so the discuss isn't >> really about the formalism. >>=20 >> S. >>=20 >>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >=20 --------------ms090500000001010801070607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDIw MDE0NTZaMC8GCSqGSIb3DQEJBDEiBCBNAsFSGP/bmsHG9aYntNgFv98SyikkqpboYbrLJx8m 7DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCmJxA8sgaz9dCdwUd/+NznmWIN/m/LxG0T3qxyHGHxnvVlGg1iFrTn tyzRpwZxF3UMipkcXfMM+TejeGNP1tpkHiJGMVazATZKKW55DZHVuZRsxlT5TF6cRhPUufih u0OFcyHXKok4D9fbkG6XNre8/kG0vv1HoSFCrAH+jmyiMtSd8dxPjjS1CXDeFN7+XTNw2hLz zzgh3AX20EL826qSZdYrveI4xoaKEMZfDuKcdvdCPJRd/mdHlPvAIX8HsxkgQ/SYaQaS7WqM 4vGKO8zw74iPaWTZG83LhEk182FR7B/20cvBCwtybD/UtSgKuCgSaRoco2ASu642dWK2O8dL AAAAAAAA --------------ms090500000001010801070607-- From nobody Wed Feb 1 16:21:47 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D411E129612; Wed, 1 Feb 2017 16:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfLfEJu77ARq; Wed, 1 Feb 2017 16:21:45 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0119.outbound.protection.outlook.com [104.47.32.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175C2129600; Wed, 1 Feb 2017 16:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wbnN7bdTYmmNlbPdbXSAEPdJmnk9775uDB1+OzdntuQ=; b=iioGLhWiL4g2xj97nJW1x2kUjM30eQwo+DgfnIEMdezw3oqs3NMNae9b6CWKrobqANDLPGPQLTnZytaHd5zF1yKOy6L6q/5nMKxkPLrcRZL7nnc3g21V/B252zM5SeRBfvebHQ0WcvrIwhCMCYu5ORcVxb3BZT2rCKP6RvX0LCg= Received: from SN1PR0301MB2029.namprd03.prod.outlook.com (10.163.226.27) by BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 00:21:42 +0000 Received: from SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) by SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) with mapi id 15.01.0860.026; Thu, 2 Feb 2017 00:21:42 +0000 From: Anthony Nadalin To: Stephen Farrell , Mike Jones , joel jaeggli , The IESG Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) Thread-Index: AQHSe97GorBcOHuDmkGNgYGkSGkYdqFUP6sAgAABIQCAACDtgIAAWs6AgAAcifCAAAH2AIAAAQaw Date: Thu, 2 Feb 2017 00:21:42 +0000 Message-ID: References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> <2dbfc379-7926-5794-22e8-1f09618ae5ea@cs.tcd.ie> In-Reply-To: <2dbfc379-7926-5794-22e8-1f09618ae5ea@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [131.107.159.71] x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-ms-office365-filtering-correlation-id: 39d8deca-5a0f-47c5-4754-08d44b017691 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR03MB2355; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2355; 7:gXGzsJcUdU6Gwz6G0lvfd6MY7kFXCV/CZHEGfS6QJmq4tnPwzzvISYadQ79Q7RrWawfF2wVblqD1TqSpq+0nYbw+mDtycSKqL7xHQDYPlW6GewGQZbKGkEI5V8XIlLmrUqF/qEb3AmN+pI/nSb++CAPbBVaI3mRpBNg+Z3+LxyAoeRQ0UgRhp9VCDQ9665oiTLDpMQUxA2rEUU1p0HkYWMKSp52vHgXQnAoBBcNSQZ35sejtgHL0CxmmWjQa9171KROjkBLc2XJ4OdHtSRBNS5Ew1U3GuEThHJvYfzcWBTymK+9WQWDXIonQLmUuXyy0x5qvXjGhG5cNtswAwTtklJsQO5g9HtvrS9poBI7XMrQNok6JMPq59Q4/N98v+Yv0wlVSFYgai+jZuqHtFnYqddc3dTk50Yy2BRhodVmtkaNAchezQinNTT0bLEu4WOeLamykxn/oipFLeFP50z0fCDFS5ndodXvzVrVGklgoJG4S0KR6eNunnmhQcTXsb8ehiz1g1u5SDFw1ZCSiykKTT0cVKCcC1McGU6HOAf/lcRpHXTQona9HVBB3VHly7CwZ x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123558025)(20161123560025)(20161123564025)(6042181)(6072148); SRVR:BN3PR03MB2355; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2355; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(24454002)(40224003)(51914003)(189002)(13464003)(199003)(51444003)(230783001)(77096006)(2900100001)(3846002)(2421001)(102836003)(5660300001)(25786008)(3280700002)(33656002)(10090500001)(2906002)(38730400001)(229853002)(4326007)(8990500004)(53936002)(92566002)(966004)(122556002)(105586002)(106356001)(106116001)(6116002)(74316002)(8676002)(99286003)(50986999)(8936002)(7736002)(76176999)(54356999)(305945005)(86612001)(68736007)(5005710100001)(10290500002)(81156014)(81166006)(1511001)(6306002)(86362001)(6506006)(66066001)(9686003)(3660700001)(6436002)(7696004)(2950100002)(2561002)(55016002)(5001770100001)(101416001)(189998001)(97736004)(54906002)(93886004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2355; H:SN1PR0301MB2029.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 00:21:42.0323 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2355 Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:21:47 -0000 VGhlIGNvZGUgcG9pbnQgaXMgdGhhdCBXaW5kb3dzIEhlbGxvIHByb3RvY29sIHN1cHBvcnRzIHRo cmVlIHR5cGVzIG9mIGJpb21ldHJpYyBhdXRoZW50aWNhdGlvbjogZmluZ2VycHJpbnQsIGZhY2Ug YW5kIGlyaXMsIHdlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiBleWUsIHJldGluYSBhbmQg aXJpcy4gVGhlcmUgYXJlIHdpbmRvd3MgZGV2aWNlcyB0aGF0IGRvIHJldGluYSBhbHNvLCBsaWtl IHdpbmRvd3MgcGhvbmVzLCB3ZSBoYXZlIG5vdyBnb25lIHRvIGlyaXMgYWZ0ZXIgdGhlIE5JU1Qg dGVzdGluZyBhbmQgdGh1cyB3YW50IHR0byBtYWtlIHN1cmUgdGhlcmUgaXMgYSB3YXkgdG8gZGlz dGluZ3Vpc2ggZHVyaW5nIHRoZSAgYXV0aGVudGljYXRpb24gc2luY2UgdGhlIGlyaXMgc2NhbiBy ZWR1Y2VzIHRoZSBwcm9iYWJpbGl0eSBvZiBlcnJvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRj ZC5pZV0gDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEsIDIwMTcgNDoxNSBQTQ0KVG86IEFu dGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPjsgTWlrZSBKb25lcyA8TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgam9lbCBqYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPjsg VGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogb2F1dGgtY2hhaXJzQGlldGYub3JnOyBkcmFm dC1pZXRmLW9hdXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt b2F1dGgtYW1yLXZhbHVlcy0wNTogKHdpdGggRElTQ1VTUykNCg0KDQpIaSBUb255LA0KDQpPbiAw Mi8wMi8xNyAwMDoxMCwgQW50aG9ueSBOYWRhbGluIHdyb3RlOg0KPiBOSVNUIGFza2VkIGZvciB0 aGUgYWRkaXRpb24gb2YgSVJJUyAoYXMgdGhleSBhcmUgc2VlaW5nIG1vcmUgdXNlIG9mDQo+IElS SVMgb3ZlciByZXRpbmEgZHVlIHRvIHRoZSBhY2N1cmFjeSBvZiBpcmlzKSAgYXMgdGhleSBoYXZl IGJlZW4NCj4gZG9pbmcgc2lnbmlmaWNhbnQgdGVzdGluZyBvbiB2YXJpb3VzIGlyaXMgZGV2aWNl cyBhbmQgY29udGludWUgdG8gZG8NCj4gc28sIGhlcmUgaXMgYSByZXBvcnQgdGhhdCBOSVNUIHJl bGVhc2VkDQo+IGh0dHA6Ly8yMDEwLTIwMTQuY29tbWVyY2UuZ292L2Jsb2cvMjAxMi8wNC8yMy9u aXN0LWlyaXMtcmVjb2duaXRpb24tcmVwb3J0LWV2YWx1YXRlcy1uZWVkbGUtaGF5c3RhY2stc2Vh cmNoLWNhcGFiaWxpdHkuaHRtbA0KPiANCg0KU29ycnksIGJ1dCB0aGF0IGRvZXNuJ3QgaGVscCBt ZSAoYXQgZmlyc3QgZ2xhbmNlIGFueXdheSkuIElmDQp0aGVyZSdzIGEgcmVmZXJlbmNlIHRoYXQn ZCBnYXJuZXIgdXMgaW50ZXJvcCwgdGhlbiBncmVhdCwganVzdA0KYWRkIGl0IHRvIG1hdGNoIHRo ZSBjb2RlcG9pbnQuIElmIHRoZXJlJ3Mgbm90LCBJIGRvbid0IHNlZSB3aHkNCmFkZGluZyBhIGNv ZGVwb2ludCBpcyB1c2VmdWwuIChFc3AuIGlmIHdlJ3JlIGF0IHRoZSBzdGFnZSBvZg0KdGVzdGlu ZyAidmFyaW91cyBpcmlzIGRldmljZXMiIHRoYXQgSSB3b3VsZCBndWVzcyBkbyBub3QgZ2V0DQp1 cyBpbnRlcm9wLikNCg0KQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KQ2hlZXJzLA0KUy4NCg0K PiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogU3RlcGhlbiBGYXJyZWxsDQo+ IFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gU2VudDogV2VkbmVzZGF5LCBGZWJy dWFyeSAxLCAyMDE3DQo+IDI6MjYgUE0gVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbT47IGpvZWwgamFlZ2dsaQ0KPiA8am9lbGphQGJvZ3VzLmNvbT47IFRoZSBJRVNH IDxpZXNnQGlldGYub3JnPiBDYzoNCj4gb2F1dGgtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRm LW9hdXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7DQo+IG9hdXRoQGlldGYub3JnIFN1YmplY3Q6IFJl OiBbT0FVVEgtV0ddIFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mgb24NCj4gZHJhZnQtaWV0Zi1v YXV0aC1hbXItdmFsdWVzLTA1OiAod2l0aCBESVNDVVNTKQ0KPiANCj4gDQo+IEhpIE1pa2UsDQo+ IA0KPiBPbiAwMS8wMi8xNyAxNzowMCwgTWlrZSBKb25lcyB3cm90ZToNCj4+IFRoYW5rcyBmb3Ig dGhlIGRpc2N1c3Npb24sIFN0ZXBoZW4uDQo+PiANCj4+IFRvIHlvdXIgcG9pbnQgYWJvdXQgIm90 cCIsIHRoZSB3b3JraW5nIGdyb3VwIGRpc2N1c3NlZCB0aGlzIHZlcnkgDQo+PiBwb2ludC4gIFRo ZXkgZXhwbGljaXRseSBkZWNpZGVkIG5vdCB0byBpbnRyb2R1Y2UgImhvdHAiIGFuZCAidG90cCIg DQo+PiBpZGVudGlmaWVycyBiZWNhdXNlIG5vIG9uZSBoYWQgYSB1c2UgY2FzZSBpbiB3aGljaCB0 aGUgZGlzdGluY3Rpb24gDQo+PiBtYXR0ZXJlZC4NCj4gDQo+IFRoZW4gSSdtIG5vdCBmb2xsb3dp bmcgd2h5IGFkZGluZyAib3RwIiB0byB0aGUgcmVnaXN0cnkgbm93IGlzIGEgZ29vZA0KPiBwbGFu Lg0KPiANCj4gSWYgdGhlcmUncyBhIHVzZS1jYXNlIG5vdywgdGhlbiBhZGRpbmcgYW4gZW50cnkg d2l0aCBhIGdvb2QgcmVmZXJlbmNlDQo+IHRvIHRoZSByZWxldmFudCBzcGVjIHNlZW1zIHJpZ2h0 Lg0KPiANCj4gSWYgdGhlcmUncyBubyB1c2UtY2FzZSBub3csIHRoZW4gbm90IGFkZGluZyBpdCB0 byB0aGUgcmVnaXN0cnkgc2VlbXMNCj4gcmlnaHQuIChNZW50aW9uaW5nIGl0IGFzIGEgcG9zc2li bGUgZnV0dXJlIGVudHJ5IHdvdWxkIGJlIGZpbmUuKQ0KPiANCj4gSSB0aGluayB0aGUgc2FtZSBs b2dpYyB3b3VsZCBhcHBseSBmb3IgYWxsIHRoZSB2YWx1ZXMgdGhhdCB0aGlzIHNwZWMNCj4gYWRk cyB0byB0aGUgcmVnaXN0cnkuIFdoeSBpcyB0aGF0IHdyb25nPw0KPiANCj4+IE90aGVycyBjYW4g Y2VydGFpbmx5IGludHJvZHVjZSB0aG9zZSBpZGVudGlmaWVycyBhbmQgcmVnaXN0ZXIgdGhlbQ0K Pj4gaWYgdGhleSBkbyBoYXZlIHN1Y2ggYSB1c2UgY2FzZSwgb25jZSB0aGUgcmVnaXN0cnkgaGFz IGJlZW4NCj4+IGVzdGFibGlzaGVkLiAgQnV0IHRoZSB3b3JraW5nIGdyb3VwIHdhbnRlZCB0byBi ZSBjb25zZXJ2YXRpdmUgYWJvdXQNCj4+IHRoZSBpZGVudGlmaWVycyBpbnRyb2R1Y2VkIHRvIHBy aW1lIHRoZSByZWdpc3RyeSwgYW5kIHRoaXMgaXMgc3VjaA0KPj4gYSBjYXNlLg0KPj4gDQo+PiBX aGF0IGlkZW50aWZpZXJzIHRvIHVzZSBhbmQgcmVnaXN0ZXIgd2lsbCBhbHdheXMgYmUgYSBiYWxh bmNpbmcNCj4+IGFjdC4gWW91IHdhbnQgdG8gYmUgYXMgc3BlY2lmaWMgYXMgbmVjZXNzYXJ5IHRv IGFkZCBwcmFjdGljYWwgYW5kDQo+PiB1c2FibGUgdmFsdWUsIGJ1dCBub3Qgc28gc3BlY2lmaWMg YXMgdG8gbWFrZSB0aGluZ3MgdW5uZWNlc3NhcmlseQ0KPj4gYnJpdHRsZS4NCj4gDQo+IEVoLi4u IGRvbid0IHdlIHdhbnQgaW50ZXJvcD8gSXNuJ3QgdGhhdCB0aGUgcHJpbWFyeSBnb2FsIGhlcmU/ DQo+IA0KPj4gV2hpbGUgc29tZSBtaWdodCBzYXkgdGhlcmUncyBhIGRpZmZlcmVuY2UgYmV0d2Vl biBzZXJpYWwgbnVtYmVyIA0KPj4gcmFuZ2VzIG9mIHBhcnRpY3VsYXIgYXV0aGVudGljYXRpb24g ZGV2aWNlcywgZ29pbmcgdGhlcmUgaXMNCj4+IGNsZWFybHkgaW4gdGhlIHdlZWRzLiAgT24gdGhl IG90aGVyIGhhbmQsIHdoaWxlIHRoZXJlIHVzZWQgdG8gYmUgYW4NCj4+ICJleWUiIGlkZW50aWZp ZXIsIEVsYWluZSBOZXd0b24gb2YgTklTVCBwb2ludGVkIG91dCB0aGF0IHRoZXJlIGFyZSANCj4+ IHNpZ25pZmljYW50IGRpZmZlcmVuY2VzIGJldHdlZW4gcmV0aW5hIGFuZCBpcmlzIG1hdGNoaW5n LCBzbyAiZXllIiANCj4+IHdhcyByZXBsYWNlZCB3aXRoICJyZXRpbmEiIGFuZCAiaXJpcyIuICBD b21tb24gc2Vuc2UgaW5mb3JtZWQgYnkgDQo+PiBhY3R1YWwgZGF0YSBpcyB0aGUga2V5IGhlcmUu DQo+IA0KPiBUaGF0J3MgYW5vdGhlciBnb29kIGV4YW1wbGUuIFRoZXJlJ3Mgbm8gcmVmZXJlbmNl IGZvciAiaXJpcy4iIElmIHRoYXQNCj4gaXMgdXNlZCBpbiBzb21lIHByb3RvY29sLCB0aGVuIHdo YXQgZm9ybWF0KHMpIGFyZSBleHBlY3RlZCB0byBiZQ0KPiBzdXBwb3J0ZWQ/IFdoZXJlIGRvIEkg ZmluZCB0aGF0IHNwZWM/IElmIHdlIGNhbiBhbnN3ZXIgdGhhdCwgdGhlbg0KPiBncmVhdCwgbGV0 J3MgYWRkIHRoZSBkZXRhaWxzLiBJZiBub3QsIHRoZW4gSSdkIHN1Z2dlc3Qgd2Ugb21pdCAiaXJp cyINCj4gYW5kIGxlYXZlIGl0ICd0aWxsIGxhdGVyIHRvIGFkZCBhbiBlbnRyeSBmb3IgdGhhdC4g QW5kIGFnYWluLA0KPiBpbmNsdWRpbmcgdGV4dCB3aXRoICJpcmlzIiBhcyBhbiBleGFtcGxlIGlz IGp1c3QgZmluZSwgYWxsIEknbSBhc2tpbmcNCj4gaXMgdGhhdCB3ZSBvbmx5IGFkZCB0aGUgcmVn aXN0cnkgZW50cnkgaWYgd2UgY2FuIG1lZXQgdGhlIHNhbWUgYmFyDQo+IHRoYXQgd2UncmUgYXNr aW5nIHRoZSBERSB0byBpbXBvc2Ugb24gbGF0ZXIgYWRkaXRpb25zLg0KPiANCj4gQW5kIHRoZSBz YW1lIGZvciBhbGwgdGhlIG90aGVycy4uLg0KPiANCj4gQ2hlZXJzLCBTLg0KPiANCj4gDQo+PiAN Cj4+IFRoZSBwb2ludCBvZiB0aGUgcmVnaXN0cnkgcmVxdWlyaW5nIGEgc3BlY2lmaWNhdGlvbiBy ZWZlcmVuY2UgaXMNCj4+IHNvIHBlb3BsZSB1c2luZyB0aGUgcmVnaXN0cnkgY2FuIHRlbGwgd2hl cmUgdGhlIGlkZW50aWZpZXIgaXMNCj4+IGRlZmluZWQuIEZvciBhbGwgdGhlIGluaXRpYWwgdmFs dWVzLCB0aGF0IHJlcXVpcmVtZW50IGlzIHNhdGlzZmllZCwNCj4+IHNpbmNlIHRoZSByZWZlcmVu Y2Ugd2lsbCBiZSB0byB0aGUgbmV3IFJGQy4gIEkgdGhpbmsgdGhhdCBhbGlnbnMNCj4+IHdpdGgg dGhlIHBvaW50IHRoYXQgSm9lbCB3YXMgbWFraW5nLg0KPj4gDQo+PiBZb3VyIHRob3VnaHRzPw0K Pj4gDQo+PiAtLSBNaWtlDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206 IE9BdXRoIA0KPj4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg U3RlcGhlbiBGYXJyZWxsIFNlbnQ6IA0KPj4gV2VkbmVzZGF5LCBGZWJydWFyeSAxLCAyMDE3IDc6 MDMgQU0gVG86IGpvZWwgamFlZ2dsaSANCj4+IDxqb2VsamFAYm9ndXMuY29tPjsgVGhlIElFU0cg PGllc2dAaWV0Zi5vcmc+IENjOiANCj4+IG9hdXRoLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0 Zi1vYXV0aC1hbXItdmFsdWVzQGlldGYub3JnOyANCj4+IG9hdXRoQGlldGYub3JnIFN1YmplY3Q6 IFJlOiBbT0FVVEgtV0ddIFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3MNCj4+IG9uIGRyYWZ0LWll dGYtb2F1dGgtYW1yLXZhbHVlcy0wNTogKHdpdGggRElTQ1VTUykNCj4+IA0KPj4gDQo+PiANCj4+ IE9uIDAxLzAyLzE3IDE0OjU4LCBqb2VsIGphZWdnbGkgd3JvdGU6DQo+Pj4gT24gMS8zMS8xNyA4 OjI2IEFNLCBTdGVwaGVuIEZhcnJlbGwgd3JvdGU6DQo+Pj4+IFN0ZXBoZW4gRmFycmVsbCBoYXMg ZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3IgDQo+Pj4+IGRyYWZ0LWll dGYtb2F1dGgtYW1yLXZhbHVlcy0wNTogRGlzY3Vzcw0KPj4+PiANCj4+Pj4gV2hlbiByZXNwb25k aW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkNCj4+Pj4g dG8gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAo RmVlbA0KPj4+PiBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2 ZXIuKQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IFBsZWFzZSByZWZlciB0byANCj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIGZvciANCj4+ Pj4gbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRp b25zLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBi YWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgDQo+Pj4+IGhlcmU6IA0KPj4+PiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMvDQo+ Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pg0KPj4+Pg0KPg0KPj4+ PiANCi0NCj4+Pj4gRElTQ1VTUzogDQo+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pg0KPj4+Pg0KPg0K Pj4+PiANCi0NCj4+Pj4gDQo+Pj4+IFRoaXMgc3BlY2lmaWNhdGlvbiBzZWVtcyB0byBtZSB0byBi cmVhayBpdCdzIG93biBydWxlcy4gWW91DQo+Pj4+IHN0YXRlIHRoYXQgcmVnaXN0cmF0aW9ucyBz aG91bGQgaW5jbHVkZSBhIHJlZmVyZW5jZSB0byBhDQo+Pj4+IHNwZWNpZmljYXRpb24gdG8gaW1w cm92ZSBpbnRlcm9wLiBBbmQgeWV0LCBmb3IgdGhlIHN0cmluZ3MNCj4+Pj4gYWRkZWQgaGVyZSAo ZS5nLiBvdHApIHlvdSBkb24ndCBkbyB0aGF0IChyZWZlcnJpbmcgdG8gc2VjdGlvbiAyDQo+Pj4+ IHdpbGwgbm90IGltcHJvdmUgaW50ZXJvcCkgYW5kIHRoZXJlIGFyZSBkaWZmZXJlbnQgd2F5cyBp biB3aGljaA0KPj4+PiBtYW55IG9mIHRoZSBtZXRob2RzIGluIHNlY3Rpb24gMiBjYW4gYmUgZG9u ZS4gU28gSSB0aGluayB5b3UNCj4+Pj4gbmVlZCB0byBhZGQgYSBidW5jaCBtb3JlIHJlZmVyZW5j ZXMuDQo+Pj4gDQo+Pj4gTm90IGNsZWFyIHRvIG1lIHRoYXQgdGhlIGRvY3VtZW50IGNyZWF0aW5n IHRoZSByZWdpc3RyeSBuZWVkcyB0bw0KPj4+ICBhZGhlcmUgdG8gdGhlIHJ1bGVzIGZvciBmdXJ0 aGVyIGFsbG9jYXRpb25zIGluIG9yZGVyIHRvDQo+Pj4gcHJlcG91bGF0ZSB0aGUgcmVnaXN0cnku IHRoYXQgaXMgcGVyaGFwcyBhbiBhcHBlYWwgdG8gZnV0dXJlDQo+Pj4gY29uc2lzdGVuY3kuDQo+ PiANCj4+IFN1cmUgLSBJJ20gYWxsIGZvciBhIHNtYXR0ZXJpbmcgb2YgaW5jb25zaXN0ZW5jeTot KQ0KPj4gDQo+PiBCdXQgSSB0aGluayB0aGUgbGFjayBvZiBzcGVjcyBpbiBzb21lIG9mIHRoZXNl IGNhc2VzIGNvdWxkIGltcGFjdA0KPj4gb24gaW50ZXJvcCwgZS5nLiBpbiB0aGUgb3RwIGNhc2Us IHRoZXkgcXVvdGUgdHdvIFJGQ3MgYW5kIHlldCBvbmx5DQo+PiBoYXZlIG9uZSB2YWx1ZS4gVGhh dCBzZWVtcyBhIGJpdCBicm9rZW4gdG8gbWUsIHNvIHRoZSBkaXNjdXNzIGlzbid0DQo+PiByZWFs bHkgYWJvdXQgdGhlIGZvcm1hbGlzbS4NCj4+IA0KPj4gUy4NCj4+IA0KPj4gDQo+Pj4+IA0KPj4+ PiANCj4+Pj4gDQo+Pj4gDQo+Pj4gDQo+PiANCj4gDQoNCg== From nobody Wed Feb 1 16:22:02 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04C5129623; Wed, 1 Feb 2017 16:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wydPqGo5TVGP; Wed, 1 Feb 2017 16:21:49 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0121.outbound.protection.outlook.com [104.47.36.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3024129622; Wed, 1 Feb 2017 16:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EUa1RnjAYUXxATUbWF1T9wdDGeuVr2y9swtNkbycyjU=; b=PDmZ5kksVSalsO7lcnXvNKi7MgPyfScUCc6IGGztid0UFF9M9mD2pvtuqf6EtS4HfqkvN/CZ08cajYGY+sG6XvKPwj+z4XIh6zyaKCv1A2Vm6LA3LgmSfLjJ8QxLvTTQZqfLJgRTqmN7ry8MdQ79BPQm6Cr65qlZW/RbVohIk+Y= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by SN1PR0301MB2032.namprd03.prod.outlook.com (10.163.226.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Thu, 2 Feb 2017 00:21:46 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0874.021; Thu, 2 Feb 2017 00:21:46 +0000 From: Mike Jones To: Anthony Nadalin , Stephen Farrell , joel jaeggli , The IESG Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) Thread-Index: AQHSe97H5hXZpqeBE0CT6lHMY4yQFKFUP6sAgAABIQCAAB5D0IAAXXiAgAAdOACAAABqIA== Date: Thu, 2 Feb 2017 00:21:45 +0000 Message-ID: References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:c::388] x-ms-office365-filtering-correlation-id: 376d856e-01f6-4810-7f1f-08d44b0178e1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN1PR0301MB2032; x-microsoft-exchange-diagnostics: 1; SN1PR0301MB2032; 7:XiTa2zJYCXFfT2mtcp93zAwMhqG1r3vfYOpsbyF573jwJo3XXfgshSBzx/co/TOeBXzfuLRqqGcF7SuVM45/zWeh1hZ3OTcvbkWSEHlt5p/WnOrzl8edvuBAlg6otptuZRNd1mHuYpMuPkjVpquoNCLS8FkFs0rz9C3aQpKSYNu4SP1sKnEfXEM4uI+v1vBAXjrWJUYxN1kFtR9mKr28PUvBi/1RGqmnxC++A5G8Hvt3C5EgRCKp+l+gzrzihy66xXYjQHbU4WYc2NKQf1u0jDKhCcC3RbBdxvAHRcmxZg0UR/2MGjT5GZxRgMlSkxLd72dKbwu89jWrL8zpNVLQw/JtB+AKoi+eY6TOjpAOvk+OhUOG21pcpw/uulDBL9nVkMe1fuDUpBWXBt86D5eAufDPpyuGKthvAyBqTDiC6a2oc2c5RbT0aXzLgDiZUvFdr6Gl87GXMHj0rv/t8VfHcdzdwRLCkhXBLlJ8dVpmimSAs2FqMCS3P/4a9KQc8GIP20qvo7cr8/rURLlzN9jYrVGxrreiXItLQ1dEW4MX1IKja7KkaVgQuKpzmjVuc961 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123555025)(20161123564025)(6072148); SRVR:SN1PR0301MB2032; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB2032; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39410400002)(39850400002)(39840400002)(377454003)(40224003)(24454002)(13464003)(51914003)(51444003)(199003)(189002)(551544002)(3900700001)(99286003)(2906002)(92566002)(106356001)(54906002)(8676002)(9686003)(77096006)(3660700001)(6506006)(38730400001)(229853002)(25786008)(6436002)(74316002)(8936002)(6306002)(81166006)(55016002)(81156014)(2421001)(106116001)(105586002)(68736007)(966004)(2561002)(102836003)(1511001)(5660300001)(93886004)(33656002)(2950100002)(6116002)(101416001)(7736002)(50986999)(10290500002)(54356999)(76176999)(305945005)(86612001)(189998001)(2900100001)(5005710100001)(53936002)(122556002)(3280700002)(5001770100001)(8990500004)(86362001)(10090500001)(97736004)(4326007)(230783001)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB2032; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 00:21:45.8835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB2032 Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:21:53 -0000 VGhhbmtzLCBUb255LiAgSSBjYW4gYWRkIHRoYXQgcmVmZXJlbmNlLg0KDQpTdGVwaGVuLCB0aGUg c2V0cyBvZiBpbml0aWFsIHZhbHVlcyB3ZXJlIGNob3NlbiBmcm9tIHRob3NlIHVzZWQgaW4gcHJh Y3RpY2UgYnkgTWljcm9zb2Z0IGFuZCBHb29nbGUgaW4gcmVhbCBkZXBsb3ltZW50cy4NCg0KQWJv dXQgIm90cCIsIHRoZXJlIGFyZSBleGlzdGluZyB1c2UgY2FzZXMgZm9yIGluZGljYXRpbmcgdGhh dCBhbiBPVFAgd2FzIHVzZWQuICBJJ20gbm90IGF3YXJlIG9mIGFueSBvZiB0aGVzZSB1c2UgY2Fz ZXMgd2hlcmUgdGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gVE9UUCBhbmQgSE9UUCBpcyBpbXBvcnRh bnQuICBUaHVzLCBoYXZpbmcgIm90cCIgbm93IG1ha2VzIHNlbnNlLCB3aGVyZSBoYXZpbmcgImhv dHAiIGFuZCAidG90cCIgbm93IGRvZXNuJ3QuDQoNClN0ZXBoZW4sIHRoaXMgbWF5IHNlZW0gbGlr ZSBzcGxpdHRpbmcgaGFpcnMsIGJ1dCB0aGUgcmVnaXN0cnkgaW5zdHJ1Y3Rpb25zIGZvciAiU3Bl Y2lmaWNhdGlvbiBEb2N1bWVudChzKSIgYXJlIGFib3V0IGhhdmluZyBhIHJlZmVyZW5jZSBmb3Ig dGhlIGRvY3VtZW50IHdoZXJlIHRoZSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIE5h bWUgKHN1Y2ggYXMgIm90cCIpIGlzIGRlZmluZWQuICBJbiBhbGwgY2FzZXMgZm9yIHRoZSBpbml0 aWFsIHZhbHVlcywgdGhpcyBpcyB0aGUgUkZDLXRvLWJlLCBzbyB0aGUgcmVnaXN0cnkgaW5zdHJ1 Y3Rpb25zIGFyZSBzYXRpc2ZpZWQuICBJZiBzb21lb25lIHdlcmUsIGZvciBpbnN0YW5jZSwgdG8g ZGVmaW5lIHRoZSBzdHJpbmcgImhvdHAiLCBpdCB3b3VsZCBiZSBpbmN1bWJlbnQgb24gdGhlIHBl cnNvbiByZXF1ZXN0aW5nIGl0cyByZWdpc3RyYXRpb24gdG8gcHJvdmlkZSBhIFVSTCB0byB0aGUg ZG9jdW1lbnQgd2hlcmUgdGhlIHN0cmluZyAiaG90cCIgaXMgZGVmaW5lZC4gIEFsc28gaGF2aW5n IGEgcmVmZXJlbmNlIHRvIFJGQyA0MjI2IGluIHRoYXQgZG9jdW1lbnQgd291bGQgYmUgYSBnb29k IHRoaW5nLCBidXQgdGhhdCBpc24ndCB3aGF0IHRoZSByZWdpc3RyeSBpbnN0cnVjdGlvbnMgYXJl IGFib3V0Lg0KDQpBbGwgdGhhdCBzYWlkLCBJIGNhbiBsb29rIGF0IGFsc28gZmluZGluZyBhcHBy b3ByaWF0ZSByZWZlcmVuY2VzIGZvciB0aGUgcmVtYWluaW5nIHZhbHVlcyB0aGF0IGRvbid0IGN1 cnJlbnRseSBoYXZlIHRoZW0uICAoQW55b25lIGdvdCBhIGdvb2QgcmVmZXJlbmNlIGZvciBwYXNz d29yZCBvciBQSU4gdG8gc3VnZ2VzdCwgZm9yIGluc3RhbmNlPykNCg0KCQkJCS0tIE1pa2UNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFudGhvbnkgTmFkYWxpbiANClNlbnQ6 IFdlZG5lc2RheSwgRmVicnVhcnkgMSwgMjAxNyA0OjEwIFBNDQpUbzogU3RlcGhlbiBGYXJyZWxs IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPjsgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0Bt aWNyb3NvZnQuY29tPjsgam9lbCBqYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPjsgVGhlIElFU0cg PGllc2dAaWV0Zi5vcmc+DQpDYzogb2F1dGgtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLW9h dXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW09B VVRILVdHXSBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtb2F1dGgtYW1y LXZhbHVlcy0wNTogKHdpdGggRElTQ1VTUykNCg0KTklTVCBhc2tlZCBmb3IgdGhlIGFkZGl0aW9u IG9mIElSSVMgKGFzIHRoZXkgYXJlIHNlZWluZyBtb3JlIHVzZSBvZiBJUklTIG92ZXIgcmV0aW5h IGR1ZSB0byB0aGUgYWNjdXJhY3kgb2YgaXJpcykgIGFzIHRoZXkgaGF2ZSBiZWVuIGRvaW5nIHNp Z25pZmljYW50IHRlc3Rpbmcgb24gdmFyaW91cyBpcmlzIGRldmljZXMgYW5kIGNvbnRpbnVlIHRv IGRvIHNvLCBoZXJlIGlzIGEgcmVwb3J0IHRoYXQgTklTVCByZWxlYXNlZCBodHRwOi8vMjAxMC0y MDE0LmNvbW1lcmNlLmdvdi9ibG9nLzIwMTIvMDQvMjMvbmlzdC1pcmlzLXJlY29nbml0aW9uLXJl cG9ydC1ldmFsdWF0ZXMtbmVlZGxlLWhheXN0YWNrLXNlYXJjaC1jYXBhYmlsaXR5Lmh0bWwgIA0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWls dG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDEsIDIwMTcgMjoyNiBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT47IGpvZWwgamFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT47IFRoZSBJRVNHIDxpZXNnQGll dGYub3JnPg0KQ2M6IG9hdXRoLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1hbXIt dmFsdWVzQGlldGYub3JnOyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g U3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMt MDU6ICh3aXRoIERJU0NVU1MpDQoNCg0KSGkgTWlrZSwNCg0KT24gMDEvMDIvMTcgMTc6MDAsIE1p a2UgSm9uZXMgd3JvdGU6DQo+IFRoYW5rcyBmb3IgdGhlIGRpc2N1c3Npb24sIFN0ZXBoZW4uDQo+ IA0KPiBUbyB5b3VyIHBvaW50IGFib3V0ICJvdHAiLCB0aGUgd29ya2luZyBncm91cCBkaXNjdXNz ZWQgdGhpcyB2ZXJ5DQo+IHBvaW50LiAgVGhleSBleHBsaWNpdGx5IGRlY2lkZWQgbm90IHRvIGlu dHJvZHVjZSAiaG90cCIgYW5kICJ0b3RwIg0KPiBpZGVudGlmaWVycyBiZWNhdXNlIG5vIG9uZSBo YWQgYSB1c2UgY2FzZSBpbiB3aGljaCB0aGUgZGlzdGluY3Rpb24NCj4gbWF0dGVyZWQuICANCg0K VGhlbiBJJ20gbm90IGZvbGxvd2luZyB3aHkgYWRkaW5nICJvdHAiIHRvIHRoZSByZWdpc3RyeSBu b3cNCmlzIGEgZ29vZCBwbGFuLg0KDQpJZiB0aGVyZSdzIGEgdXNlLWNhc2Ugbm93LCB0aGVuIGFk ZGluZyBhbiBlbnRyeSB3aXRoIGEgZ29vZA0KcmVmZXJlbmNlIHRvIHRoZSByZWxldmFudCBzcGVj IHNlZW1zIHJpZ2h0Lg0KDQpJZiB0aGVyZSdzIG5vIHVzZS1jYXNlIG5vdywgdGhlbiBub3QgYWRk aW5nIGl0IHRvIHRoZQ0KcmVnaXN0cnkgc2VlbXMgcmlnaHQuIChNZW50aW9uaW5nIGl0IGFzIGEg cG9zc2libGUgZnV0dXJlDQplbnRyeSB3b3VsZCBiZSBmaW5lLikNCg0KSSB0aGluayB0aGUgc2Ft ZSBsb2dpYyB3b3VsZCBhcHBseSBmb3IgYWxsIHRoZSB2YWx1ZXMgdGhhdA0KdGhpcyBzcGVjIGFk ZHMgdG8gdGhlIHJlZ2lzdHJ5LiBXaHkgaXMgdGhhdCB3cm9uZz8NCg0KPiBPdGhlcnMgY2FuIGNl cnRhaW5seSBpbnRyb2R1Y2UgdGhvc2UgaWRlbnRpZmllcnMgYW5kDQo+IHJlZ2lzdGVyIHRoZW0g aWYgdGhleSBkbyBoYXZlIHN1Y2ggYSB1c2UgY2FzZSwgb25jZSB0aGUgcmVnaXN0cnkgaGFzDQo+ IGJlZW4gZXN0YWJsaXNoZWQuICBCdXQgdGhlIHdvcmtpbmcgZ3JvdXAgd2FudGVkIHRvIGJlIGNv bnNlcnZhdGl2ZQ0KPiBhYm91dCB0aGUgaWRlbnRpZmllcnMgaW50cm9kdWNlZCB0byBwcmltZSB0 aGUgcmVnaXN0cnksIGFuZCB0aGlzIGlzDQo+IHN1Y2ggYSBjYXNlLg0KPiANCj4gV2hhdCBpZGVu dGlmaWVycyB0byB1c2UgYW5kIHJlZ2lzdGVyIHdpbGwgYWx3YXlzIGJlIGEgYmFsYW5jaW5nIGFj dC4NCj4gWW91IHdhbnQgdG8gYmUgYXMgc3BlY2lmaWMgYXMgbmVjZXNzYXJ5IHRvIGFkZCBwcmFj dGljYWwgYW5kIHVzYWJsZQ0KPiB2YWx1ZSwgYnV0IG5vdCBzbyBzcGVjaWZpYyBhcyB0byBtYWtl IHRoaW5ncyB1bm5lY2Vzc2FyaWx5IGJyaXR0bGUuDQoNCkVoLi4uIGRvbid0IHdlIHdhbnQgaW50 ZXJvcD8gSXNuJ3QgdGhhdCB0aGUgcHJpbWFyeSBnb2FsIGhlcmU/DQoNCj4gV2hpbGUgc29tZSBt aWdodCBzYXkgdGhlcmUncyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBzZXJpYWwgbnVtYmVyDQo+IHJh bmdlcyBvZiBwYXJ0aWN1bGFyIGF1dGhlbnRpY2F0aW9uIGRldmljZXMsIGdvaW5nIHRoZXJlIGlz IGNsZWFybHkNCj4gaW4gdGhlIHdlZWRzLiAgT24gdGhlIG90aGVyIGhhbmQsIHdoaWxlIHRoZXJl IHVzZWQgdG8gYmUgYW4gImV5ZSINCj4gaWRlbnRpZmllciwgRWxhaW5lIE5ld3RvbiBvZiBOSVNU IHBvaW50ZWQgb3V0IHRoYXQgdGhlcmUgYXJlDQo+IHNpZ25pZmljYW50IGRpZmZlcmVuY2VzIGJl dHdlZW4gcmV0aW5hIGFuZCBpcmlzIG1hdGNoaW5nLCBzbyAiZXllIg0KPiB3YXMgcmVwbGFjZWQg d2l0aCAicmV0aW5hIiBhbmQgImlyaXMiLiAgQ29tbW9uIHNlbnNlIGluZm9ybWVkIGJ5DQo+IGFj dHVhbCBkYXRhIGlzIHRoZSBrZXkgaGVyZS4NCg0KVGhhdCdzIGFub3RoZXIgZ29vZCBleGFtcGxl LiBUaGVyZSdzIG5vIHJlZmVyZW5jZSBmb3IgImlyaXMuIiBJZg0KdGhhdCBpcyB1c2VkIGluIHNv bWUgcHJvdG9jb2wsIHRoZW4gd2hhdCBmb3JtYXQocykgYXJlIGV4cGVjdGVkDQp0byBiZSBzdXBw b3J0ZWQ/IFdoZXJlIGRvIEkgZmluZCB0aGF0IHNwZWM/IElmIHdlIGNhbiBhbnN3ZXIgdGhhdCwN CnRoZW4gZ3JlYXQsIGxldCdzIGFkZCB0aGUgZGV0YWlscy4gSWYgbm90LCB0aGVuIEknZCBzdWdn ZXN0IHdlDQpvbWl0ICJpcmlzIiBhbmQgbGVhdmUgaXQgJ3RpbGwgbGF0ZXIgdG8gYWRkIGFuIGVu dHJ5IGZvciB0aGF0Lg0KQW5kIGFnYWluLCBpbmNsdWRpbmcgdGV4dCB3aXRoICJpcmlzIiBhcyBh biBleGFtcGxlIGlzIGp1c3QgZmluZSwNCmFsbCBJJ20gYXNraW5nIGlzIHRoYXQgd2Ugb25seSBh ZGQgdGhlIHJlZ2lzdHJ5IGVudHJ5IGlmIHdlIGNhbg0KbWVldCB0aGUgc2FtZSBiYXIgdGhhdCB3 ZSdyZSBhc2tpbmcgdGhlIERFIHRvIGltcG9zZSBvbiBsYXRlcg0KYWRkaXRpb25zLg0KDQpBbmQg dGhlIHNhbWUgZm9yIGFsbCB0aGUgb3RoZXJzLi4uDQoNCkNoZWVycywNClMuDQoNCg0KPiANCj4g VGhlIHBvaW50IG9mIHRoZSByZWdpc3RyeSByZXF1aXJpbmcgYSBzcGVjaWZpY2F0aW9uIHJlZmVy ZW5jZSBpcyBzbw0KPiBwZW9wbGUgdXNpbmcgdGhlIHJlZ2lzdHJ5IGNhbiB0ZWxsIHdoZXJlIHRo ZSBpZGVudGlmaWVyIGlzIGRlZmluZWQuDQo+IEZvciBhbGwgdGhlIGluaXRpYWwgdmFsdWVzLCB0 aGF0IHJlcXVpcmVtZW50IGlzIHNhdGlzZmllZCwgc2luY2UgdGhlDQo+IHJlZmVyZW5jZSB3aWxs IGJlIHRvIHRoZSBuZXcgUkZDLiAgSSB0aGluayB0aGF0IGFsaWducyB3aXRoIHRoZSBwb2ludA0K PiB0aGF0IEpvZWwgd2FzIG1ha2luZy4NCj4gDQo+IFlvdXIgdGhvdWdodHM/DQo+IA0KPiAtLSBN aWtlDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBPQXV0aA0KPiBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwg U2VudDoNCj4gV2VkbmVzZGF5LCBGZWJydWFyeSAxLCAyMDE3IDc6MDMgQU0gVG86IGpvZWwgamFl Z2dsaQ0KPiA8am9lbGphQGJvZ3VzLmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPiBDYzoN Cj4gb2F1dGgtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXNAaWV0 Zi5vcmc7DQo+IG9hdXRoQGlldGYub3JnIFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFN0ZXBoZW4g RmFycmVsbCdzIERpc2N1c3Mgb24NCj4gZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTA1OiAo d2l0aCBESVNDVVNTKQ0KPiANCj4gDQo+IA0KPiBPbiAwMS8wMi8xNyAxNDo1OCwgam9lbCBqYWVn Z2xpIHdyb3RlOg0KPj4gT24gMS8zMS8xNyA4OjI2IEFNLCBTdGVwaGVuIEZhcnJlbGwgd3JvdGU6 DQo+Pj4gU3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvciANCj4+PiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6IERpc2N1c3MN Cj4+PiANCj4+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0bw0KPj4+IGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4g dGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZQ0KPj4+IHRvIGN1dCB0aGlzIGludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPj4+IA0KPj4+IA0KPj4+IFBsZWFzZSByZWZlciB0 byANCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRl cmlhLmh0bWwgZm9yDQo+Pj4gbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5k IENPTU1FTlQgcG9zaXRpb25zLg0KPj4+IA0KPj4+IA0KPj4+IFRoZSBkb2N1bWVudCwgYWxvbmcg d2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQNCj4+PiBoZXJlOiANCj4+ PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFtci12 YWx1ZXMvDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+PiANCi0N Cj4+PiBESVNDVVNTOiANCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pg0KPj4+IA0KLQ0KPj4+IA0KPj4+ IFRoaXMgc3BlY2lmaWNhdGlvbiBzZWVtcyB0byBtZSB0byBicmVhayBpdCdzIG93biBydWxlcy4g WW91IHN0YXRlDQo+Pj4gIHRoYXQgcmVnaXN0cmF0aW9ucyBzaG91bGQgaW5jbHVkZSBhIHJlZmVy ZW5jZSB0byBhIHNwZWNpZmljYXRpb24NCj4+PiB0byBpbXByb3ZlIGludGVyb3AuIEFuZCB5ZXQs IGZvciB0aGUgc3RyaW5ncyBhZGRlZCBoZXJlIChlLmcuDQo+Pj4gb3RwKSB5b3UgZG9uJ3QgZG8g dGhhdCAocmVmZXJyaW5nIHRvIHNlY3Rpb24gMiB3aWxsIG5vdCBpbXByb3ZlDQo+Pj4gaW50ZXJv cCkgYW5kIHRoZXJlIGFyZSBkaWZmZXJlbnQgd2F5cyBpbiB3aGljaCBtYW55IG9mIHRoZQ0KPj4+ IG1ldGhvZHMgaW4gc2VjdGlvbiAyIGNhbiBiZSBkb25lLiBTbyBJIHRoaW5rIHlvdSBuZWVkIHRv IGFkZCBhDQo+Pj4gYnVuY2ggbW9yZSByZWZlcmVuY2VzLg0KPj4gDQo+PiBOb3QgY2xlYXIgdG8g bWUgdGhhdCB0aGUgZG9jdW1lbnQgY3JlYXRpbmcgdGhlIHJlZ2lzdHJ5IG5lZWRzIHRvIA0KPj4g YWRoZXJlIHRvIHRoZSBydWxlcyBmb3IgZnVydGhlciBhbGxvY2F0aW9ucyBpbiBvcmRlciB0byBw cmVwb3VsYXRlDQo+PiB0aGUgcmVnaXN0cnkuIHRoYXQgaXMgcGVyaGFwcyBhbiBhcHBlYWwgdG8g ZnV0dXJlIGNvbnNpc3RlbmN5Lg0KPiANCj4gU3VyZSAtIEknbSBhbGwgZm9yIGEgc21hdHRlcmlu ZyBvZiBpbmNvbnNpc3RlbmN5Oi0pDQo+IA0KPiBCdXQgSSB0aGluayB0aGUgbGFjayBvZiBzcGVj cyBpbiBzb21lIG9mIHRoZXNlIGNhc2VzIGNvdWxkIGltcGFjdCBvbg0KPiBpbnRlcm9wLCBlLmcu IGluIHRoZSBvdHAgY2FzZSwgdGhleSBxdW90ZSB0d28gUkZDcyBhbmQgeWV0IG9ubHkgaGF2ZQ0K PiBvbmUgdmFsdWUuIFRoYXQgc2VlbXMgYSBiaXQgYnJva2VuIHRvIG1lLCBzbyB0aGUgZGlzY3Vz cyBpc24ndCByZWFsbHkNCj4gYWJvdXQgdGhlIGZvcm1hbGlzbS4NCj4gDQo+IFMuDQo+IA0KPiAN Cj4+PiANCj4+PiANCj4+PiANCj4+IA0KPj4gDQo+IA0KDQo= From nobody Wed Feb 1 16:24:23 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9956012960A; Wed, 1 Feb 2017 16:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGO_gtqNvs-4; Wed, 1 Feb 2017 16:24:15 -0800 (PST) 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 D6C0D129577; Wed, 1 Feb 2017 16:24:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5A51ABE58; Thu, 2 Feb 2017 00:24:12 +0000 (GMT) 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 H6TffSlAKAu3; Thu, 2 Feb 2017 00:24:06 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 22C42BE3E; Thu, 2 Feb 2017 00:24:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485995046; bh=LLxbcnD5NA9NU4a+qgTI5C+MxDA+sDDJWlQTGouCdwY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=fTUmpo3SPFjaq6QJZYbjTBwjgQjoUQZiOrLu2hJDf+J513Im/OqN9mV+bnnaO0kMJ KWrwHPjveQpz50ERWY8qkmDwEObbWWKujX3WWgTApVD8XAriEvGdv9zVKHHyIA4dvh CRdiB2/506wZNhbGwKlupVSi5CrgWDtHeOPdRBfQ= To: Mike Jones , Anthony Nadalin , joel jaeggli , The IESG References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <268ffcf0-2f90-049e-1a3c-03b39d62c338@cs.tcd.ie> Date: Thu, 2 Feb 2017 00:24:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040906030700080104080206" Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:24:17 -0000 This is a cryptographically signed message in MIME format. --------------ms040906030700080104080206 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/02/17 00:21, Mike Jones wrote: > Thanks, Tony. I can add that reference. >=20 > Stephen, the sets of initial values were chosen from those used in > practice by Microsoft and Google in real deployments. Genuine questions: do you aim to have interop between those deployments? What if I wanted to write code that'd interop with msft or google? S. >=20 > About "otp", there are existing use cases for indicating that an OTP > was used. I'm not aware of any of these use cases where the > distinction between TOTP and HOTP is important. Thus, having "otp" > now makes sense, where having "hotp" and "totp" now doesn't. >=20 > Stephen, this may seem like splitting hairs, but the registry > instructions for "Specification Document(s)" are about having a > reference for the document where the Authentication Method Reference > Name (such as "otp") is defined. In all cases for the initial > values, this is the RFC-to-be, so the registry instructions are > satisfied. If someone were, for instance, to define the string > "hotp", it would be incumbent on the person requesting its > registration to provide a URL to the document where the string "hotp" > is defined. Also having a reference to RFC 4226 in that document > would be a good thing, but that isn't what the registry instructions > are about. >=20 > All that said, I can look at also finding appropriate references for > the remaining values that don't currently have them. (Anyone got a > good reference for password or PIN to suggest, for instance?) >=20 > -- Mike >=20 > -----Original Message----- From: Anthony Nadalin Sent: Wednesday, > February 1, 2017 4:10 PM To: Stephen Farrell > ; Mike Jones > ; joel jaeggli ; The > IESG Cc: oauth-chairs@ietf.org; > draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org Subject: RE: > [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) >=20 > NIST asked for the addition of IRIS (as they are seeing more use of > IRIS over retina due to the accuracy of iris) as they have been > doing significant testing on various iris devices and continue to do > so, here is a report that NIST released > http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-rep= ort-evaluates-needle-haystack-search-capability.html >=20 >=20 > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, February 1, 2017 > 2:26 PM To: Mike Jones ; joel jaeggli > ; The IESG Cc: > oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org; > oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) >=20 >=20 > Hi Mike, >=20 > On 01/02/17 17:00, Mike Jones wrote: >> Thanks for the discussion, Stephen. >>=20 >> To your point about "otp", the working group discussed this very=20 >> point. They explicitly decided not to introduce "hotp" and "totp"=20 >> identifiers because no one had a use case in which the distinction=20 >> mattered. >=20 > Then I'm not following why adding "otp" to the registry now is a good > plan. >=20 > If there's a use-case now, then adding an entry with a good reference > to the relevant spec seems right. >=20 > If there's no use-case now, then not adding it to the registry seems > right. (Mentioning it as a possible future entry would be fine.) >=20 > I think the same logic would apply for all the values that this spec > adds to the registry. Why is that wrong? >=20 >> Others can certainly introduce those identifiers and register them >> if they do have such a use case, once the registry has been >> established. But the working group wanted to be conservative about >> the identifiers introduced to prime the registry, and this is such >> a case. >>=20 >> What identifiers to use and register will always be a balancing >> act. You want to be as specific as necessary to add practical and >> usable value, but not so specific as to make things unnecessarily >> brittle. >=20 > Eh... don't we want interop? Isn't that the primary goal here? >=20 >> While some might say there's a difference between serial number=20 >> ranges of particular authentication devices, going there is >> clearly in the weeds. On the other hand, while there used to be an >> "eye" identifier, Elaine Newton of NIST pointed out that there are=20 >> significant differences between retina and iris matching, so "eye"=20 >> was replaced with "retina" and "iris". Common sense informed by=20 >> actual data is the key here. >=20 > That's another good example. There's no reference for "iris." If that > is used in some protocol, then what format(s) are expected to be > supported? Where do I find that spec? If we can answer that, then > great, let's add the details. If not, then I'd suggest we omit "iris" > and leave it 'till later to add an entry for that. And again, > including text with "iris" as an example is just fine, all I'm asking > is that we only add the registry entry if we can meet the same bar > that we're asking the DE to impose on later additions. >=20 > And the same for all the others... >=20 > Cheers, S. >=20 >=20 >>=20 >> The point of the registry requiring a specification reference is >> so people using the registry can tell where the identifier is >> defined. For all the initial values, that requirement is satisfied, >> since the reference will be to the new RFC. I think that aligns >> with the point that Joel was making. >>=20 >> Your thoughts? >>=20 >> -- Mike >>=20 >> -----Original Message----- From: OAuth=20 >> [mailto:oauth-bounces@ietf.org] On Behalf Of Stephen Farrell Sent:=20 >> Wednesday, February 1, 2017 7:03 AM To: joel jaeggli=20 >> ; The IESG Cc:=20 >> oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org;=20 >> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss >> on draft-ietf-oauth-amr-values-05: (with DISCUSS) >>=20 >>=20 >>=20 >> On 01/02/17 14:58, joel jaeggli wrote: >>> On 1/31/17 8:26 AM, Stephen Farrell wrote: >>>> Stephen Farrell has entered the following ballot position for=20 >>>> draft-ietf-oauth-amr-values-05: Discuss >>>>=20 >>>> 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.) >>>>=20 >>>>=20 >>>> Please refer to=20 >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for=20 >>>> more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found=20 >>>> here:=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ >>>>=20 >>>>=20 >>>>=20 >>>> --------------------------------------------------------------------= - >>>> >>>> > >>>>=20 - >>>> DISCUSS:=20 >>>> --------------------------------------------------------------------= - >>>> >>>> > >>>>=20 - >>>>=20 >>>> This specification seems to me to break it's own rules. You >>>> state that registrations should include a reference to a >>>> specification to improve interop. And yet, for the strings >>>> added here (e.g. otp) you don't do that (referring to section 2 >>>> will not improve interop) and there are different ways in which >>>> many of the methods in section 2 can be done. So I think you >>>> need to add a bunch more references. >>>=20 >>> Not clear to me that the document creating the registry needs to >>> adhere to the rules for further allocations in order to >>> prepoulate the registry. that is perhaps an appeal to future >>> consistency. >>=20 >> Sure - I'm all for a smattering of inconsistency:-) >>=20 >> But I think the lack of specs in some of these cases could impact >> on interop, e.g. in the otp case, they quote two RFCs and yet only >> have one value. That seems a bit broken to me, so the discuss isn't >> really about the formalism. >>=20 >> S. >>=20 >>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >=20 --------------ms040906030700080104080206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDIw MDI0MDVaMC8GCSqGSIb3DQEJBDEiBCDMEfAISmrFMWeGyeWkihHIOdb56HZOqGkmJuUYaeu7 IjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAw710Llpa5KYNNOB6qGwDBJ15QC1lWZwUIZ70VKVjgLJW260FbiOtV b2IG6FJG6MLj3L357FheeDiEh+pW4GON9FIyWruXiveYkmStaP32nOPhDh+yIjYGhqFzviMj /MLAwyCkNCY+3bPgXdpO6Fpytu8rx4asOGK+G1EWew4+HJGa5IoZdmyBQ2zlB3pcMy9QVNaw /dpi2jx7F0ceHs5c7+9vumqUBTw1cNI8Wxeb2cb4vo7J/qgqMKzVGmBZbCVdREIy8Nc27Gx9 nPw9ex9ufYi7sh3MIuA0/mq1Z0yyRVqld+7fkmKqmH9qY00UBLCitDF8V/DQmgDs4X1easKZ AAAAAAAA --------------ms040906030700080104080206-- From nobody Wed Feb 1 16:26:59 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0E9129615 for ; Wed, 1 Feb 2017 16:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lAC6xdJMU3q for ; Wed, 1 Feb 2017 16:26:56 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 6343E1295F2 for ; Wed, 1 Feb 2017 16:26:56 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id 96so448510uaq.3 for ; Wed, 01 Feb 2017 16:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X6VsPYmHtXTA9UQ0v6vq+tnvu8sfuKpQaI6bgp5mHgk=; b=Fs6vS0O5E/KdWk4GsX1A1JPt40uGRO2P2us4a3chmaMHOSqsDSAD0dNCTxyOJUyQPV bAp5arX8AqG2Hms8m4JekBDM/LasC5P6p7n9GuBdVptmgUY4z8TEYGN0Qxak1XSqzWsE CXn70AmAFAoTKbtmX/z1xE/wSkqzPyTsdLwQVvFsfbAQZv5wQ1Vak8A+tiadhcyX0yTb 3hbudOl1lPa7IURQNLV/IT10RcvNa0J/fNaRZkfBNLCvVzjNIbZnSUGTBRKDZItgicKA OmTyCwcSosa9NtxyXwzVVBEZPYKP5qC1ISVE+ScLK8zdofAu3Y/0FV5gtSJK7BJ2Jk+O D5bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X6VsPYmHtXTA9UQ0v6vq+tnvu8sfuKpQaI6bgp5mHgk=; b=IogJqVe0BjlXexeGIIeDrq41idIhPsNLIE32/SUyRedB/I7ZSmXoi3CfmJsYXcBBO+ UMLBHX+xR8uQbu60MDBJjDg8k0IXGQlICLqU7a+fkobGLLGuL5GtY1bhaPxF9njOln/8 QhBptzja4yMU5pO4/fLASmQpbDSOfY7EIU9xBRFbUoSBILe50oM/kJxqvPSQ1s8xCf4g euevP6w7tBYcLhIO1jKptcogdH+u/ggADGPmimpnomQlk1S05bl5sncXUInNL2x4JaFs sboUOkaL3c4UXhD1DtA7skl/0h8jb38iJ+HMtSBoC3ttn61MFL7GbivHCVwE0UYKHry1 v6NQ== X-Gm-Message-State: AIkVDXLw3fhcbcLygm2ZzW3X2r9f1z03v7XhWTaaUUTlOx4eI0aC/943ic+CahykuX10Mw== X-Received: by 10.176.71.87 with SMTP id i23mr2864422uac.144.1485995215386; Wed, 01 Feb 2017 16:26:55 -0800 (PST) Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com. [209.85.217.181]) by smtp.gmail.com with ESMTPSA id u78sm7889420uau.13.2017.02.01.16.26.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 16:26:54 -0800 (PST) Received: by mail-ua0-f181.google.com with SMTP id 35so490790uak.1; Wed, 01 Feb 2017 16:26:54 -0800 (PST) X-Received: by 10.176.68.65 with SMTP id m59mr2928222uam.85.1485995214594; Wed, 01 Feb 2017 16:26:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.36.132 with HTTP; Wed, 1 Feb 2017 16:26:54 -0800 (PST) In-Reply-To: <5E393DF26B791A428E5F003BB6C5342AC1CD7488@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AC1CD7488@OC11EXPO33.exchange.mit.edu> From: Aaron Parecki Date: Wed, 1 Feb 2017 16:26:54 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Thomas Hardjono Content-Type: multipart/alternative; boundary=94eb2c083012e76c9c0547813810 Archived-At: Cc: "oauth@ietf.org" , "oauth-chairs@ietf.org" Subject: Re: [OAUTH-WG] Decentralized OAuth2.0 -- FW: New Version Notification for draft-hardjono-oauth-decentralized-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:26:58 -0000 --94eb2c083012e76c9c0547813810 Content-Type: text/plain; charset=UTF-8 The introduction sounds great, especially acknowledging the problems due to "the predominance of the web single sign-on model as the basis for the user interaction"... but is there a summary of what this actually describes? I see a lot of boilerplate text, and defining some new terms, but I don't actually know what I would implement after reading this. ---- Aaron Parecki aaronparecki.com @aaronpk On Wed, Feb 1, 2017 at 3:48 PM, Thomas Hardjono wrote: > > Folks, > > This may be of interest. Its forward-looking, I know. Appreciate any > comments on the draft. > > Best. > > /thomas/ > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Wednesday, February 01, 2017 6:39 PM > To: Thomas Hardjono > Subject: New Version Notification for draft-hardjono-oauth- > decentralized-00.txt > > A new version of I-D, draft-hardjono-oauth-decentralized-00.txt > has been successfully submitted by Thomas Hardjono and posted to the > IETF repository. > > Name: draft-hardjono-oauth-decentralized > Revision: 00 > Title: Decentralized Service Architecture for OAuth2.0 > Document date: 2017-02-01 > Group: Individual Submission > Pages: 21 > URL: https://www.ietf.org/internet-drafts/draft-hardjono-oauth- > decentralized-00.txt > Status: https://datatracker.ietf.org/doc/draft-hardjono-oauth- > decentralized/ > Htmlized: https://tools.ietf.org/html/draft-hardjono-oauth- > decentralized-00 > > > Abstract: > This document proposes an alternative service architecture for user- > centric control of the sharing of resources, such as personal data, > using the decentralized peer-to-peer computing paradigm. The term > 'control' is used here to denote the full capacity of the user to > freely select (i) the entities with whom to share resources (e.g. > data), and (ii) the entities which provide services implementing > user-controlled resource sharing. The peer-to-peer service > architecture uses a set of computing nodes called OAuth2.0 Nodes (ON) > that are part of a peer-to-peer network as the basis for the > decentralized service architecture. Each OAuth2.0 Nodes is assumed > to have the capability to provide AS-services, RS-services and > Client-services. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --94eb2c083012e76c9c0547813810 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The introduction sounds great, especially acknowledging th= e problems due to "the predominance of the web single sign-on=C2=A0model as the basis for t= he user interaction"... but is there a summary of what this ac= tually describes? I see a lot of boilerplate text, and defining some new te= rms, but I don't actually know what I would implement after reading thi= s.

----
Aa= ron Parecki


On Wed, Feb 1, 2017 at 3:48 PM, Thomas Hardj= ono <hardjono@mit.edu> wrote:

Folks,

This may be of interest. Its forward-looking, I know. Appreciate any commen= ts on the draft.

Best.

/thomas/

________________________________________
From: internet-drafts@ietf.org<= /a> [internet-drafts@ietf.org]
Sent: Wednesday, February 01, 2017 6:39 PM
To: Thomas Hardjono
Subject: New Version Notification for draft-hardjono-oauth-decentraliz= ed-00.txt

A new version of I-D, draft-hardjono-oauth-decentralized-00.txt
has been successfully submitted by Thomas Hardjono and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-hardjono-oauth-dec= entralized
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Decentralized Service Architecture= for OAuth2.0
Document date:=C2=A0 2017-02-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 21
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-har= djono-oauth-decentralized-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hardjono-oauth-de= centralized/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-0= 0


Abstract:
=C2=A0 =C2=A0This document proposes an alternative service architecture for= user-
=C2=A0 =C2=A0centric control of the sharing of resources, such as personal = data,
=C2=A0 =C2=A0using the decentralized peer-to-peer computing paradigm.=C2=A0= The term
=C2=A0 =C2=A0'control' is used here to denote the full capacity of = the user to
=C2=A0 =C2=A0freely select (i) the entities with whom to share resources (e= .g.
=C2=A0 =C2=A0data), and (ii) the entities which provide services implementi= ng
=C2=A0 =C2=A0user-controlled resource sharing.=C2=A0 The peer-to-peer servi= ce
=C2=A0 =C2=A0architecture uses a set of computing nodes called OAuth2.0 Nod= es (ON)
=C2=A0 =C2=A0that are part of a peer-to-peer network as the basis for the =C2=A0 =C2=A0decentralized service architecture.=C2=A0 Each OAuth2.0 Nodes = is assumed
=C2=A0 =C2=A0to have the capability to provide AS-services, RS-services and=
=C2=A0 =C2=A0Client-services.





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

The IETF Secretariat

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

--94eb2c083012e76c9c0547813810-- From nobody Wed Feb 1 16:27:22 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16854129619; Wed, 1 Feb 2017 16:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulvTR7qy2HwW; Wed, 1 Feb 2017 16:27:15 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0117.outbound.protection.outlook.com [104.47.32.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9C101294F0; Wed, 1 Feb 2017 16:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QAR8gYyrYwmLMlmG6wP6MjbfegQ+DDQ7p3QCtMwxYYk=; b=Zqz0DzfhytwSTICykW9GCx73z5gr/3wPSztrOsrtO4E8YWXMX72q3sz1ZsFPCGGQvf4ktn4Prb+oVRw+KY79Zlkgw6B1+qK6moF7lo7HJ5H7QfVa+StawiVBbU5fvyqcsKspyFfH3DUjmRsQBaMkfpNy3AEGu3RGeIVyHE3CHXQ= Received: from SN1PR0301MB2029.namprd03.prod.outlook.com (10.163.226.27) by SN2PR03MB2368.namprd03.prod.outlook.com (10.166.210.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 00:27:12 +0000 Received: from SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) by SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) with mapi id 15.01.0860.026; Thu, 2 Feb 2017 00:27:12 +0000 From: Anthony Nadalin To: Stephen Farrell , Mike Jones , joel jaeggli , The IESG Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) Thread-Index: AQHSe97GorBcOHuDmkGNgYGkSGkYdqFUP6sAgAABIQCAACDtgIAAWs6AgAAcifCAAAPdgIAAAKeAgAAArSA= Date: Thu, 2 Feb 2017 00:27:12 +0000 Message-ID: References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> <268ffcf0-2f90-049e-1a3c-03b39d62c338@cs.tcd.ie> In-Reply-To: <268ffcf0-2f90-049e-1a3c-03b39d62c338@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [131.107.159.71] x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-ms-office365-filtering-correlation-id: 0477e73d-d6ea-4c15-fa00-08d44b023b5c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN2PR03MB2368; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2368; 7:sM4wlz+BC7v25eZmS0u2Et0NH3N3qwkB411bIyYQ6VtWO4a13YJs+XDGzv2a2zM35wyxr6oHLa/QT3LiPYWLEEbGchk94Mif2xOIl/mjlChMbA1Wx5TKZC2FAQeP34yNT05pVCzmiVOk2JVGRHVQKQRdnHC9oDBXiFiePAC86XjMNh/9EsHYruMrSHYS40OduONvq9PLXCP4Z18Vd/3hvmIu5k3E/9HmwfmjmPgNiHM1fmV4xWXooGrEqaMhAU2RpJl7YmtjGZbCVXxCw/lFulHgMrZhxR/5TbqLCzUh4WqTLFL12mEPVL3EhWRsT46zHMw1boFG/t74dSyVNQl+9CWfGmEv074lBmZj4uFc39G1HUhEOy7u+xPfPJe3oC6V/FKGNJ0DzzS8LCANaa+ZYJxiEzMa9pWTbaNd/0r+QBIs0KfdJlbB61TXgcZd3qqYqPLppY7Gj74fVtCzC0ietNsZO324GjwspQQr4K/anYKihugNYpVznvbD0HOyiyaQ/274YAlCHx5A+AYDpSiQUIL5W2WK1PitqHBdCN/Wg3Ek45tLIITsDjAZCGgE/5Rd x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123558025)(20161123562025)(6072148); SRVR:SN2PR03MB2368; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2368; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39410400002)(39860400002)(39850400002)(51444003)(51914003)(24454002)(13464003)(189002)(40224003)(377454003)(199003)(77096006)(3846002)(33656002)(86362001)(2421001)(25786008)(99286003)(106356001)(97736004)(106116001)(189998001)(105586002)(5001770100001)(8936002)(76176999)(81156014)(81166006)(10290500002)(38730400001)(50986999)(86612001)(8990500004)(5005710100001)(54356999)(8676002)(6506006)(122556002)(6436002)(10090500001)(2561002)(229853002)(68736007)(230783001)(66066001)(551544002)(966004)(93886004)(1511001)(3660700001)(4326007)(6116002)(9686003)(53936002)(101416001)(92566002)(5660300001)(102836003)(6306002)(3280700002)(3900700001)(55016002)(7736002)(305945005)(74316002)(54906002)(2900100001)(7696004)(2906002)(2950100002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR03MB2368; H:SN1PR0301MB2029.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 00:27:12.1266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2368 Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:27:18 -0000 V2UgaGF2ZSBpbnRlcm9wZWQgYmV0d2VlbiBGSURPIGF1dGhlbnRpY2F0b3JzIHZlbmRvcnMgYW5k IFdpbmRvd3MgSGVsbG8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZXBo ZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdIA0KU2VudDogV2Vk bmVzZGF5LCBGZWJydWFyeSAxLCAyMDE3IDQ6MjQgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20+OyBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0 LmNvbT47IGpvZWwgamFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT47IFRoZSBJRVNHIDxpZXNnQGll dGYub3JnPg0KQ2M6IG9hdXRoLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1hbXIt dmFsdWVzQGlldGYub3JnOyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g U3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMt MDU6ICh3aXRoIERJU0NVU1MpDQoNCg0KDQpPbiAwMi8wMi8xNyAwMDoyMSwgTWlrZSBKb25lcyB3 cm90ZToNCj4gVGhhbmtzLCBUb255LiAgSSBjYW4gYWRkIHRoYXQgcmVmZXJlbmNlLg0KPiANCj4g U3RlcGhlbiwgdGhlIHNldHMgb2YgaW5pdGlhbCB2YWx1ZXMgd2VyZSBjaG9zZW4gZnJvbSB0aG9z ZSB1c2VkIGluDQo+IHByYWN0aWNlIGJ5IE1pY3Jvc29mdCBhbmQgR29vZ2xlIGluIHJlYWwgZGVw bG95bWVudHMuDQoNCkdlbnVpbmUgcXVlc3Rpb25zOiBkbyB5b3UgYWltIHRvIGhhdmUgaW50ZXJv cCBiZXR3ZWVuIHRob3NlDQpkZXBsb3ltZW50cz8gV2hhdCBpZiBJIHdhbnRlZCB0byB3cml0ZSBj b2RlIHRoYXQnZCBpbnRlcm9wDQp3aXRoIG1zZnQgb3IgZ29vZ2xlPw0KDQpTLg0KDQo+IA0KPiBB Ym91dCAib3RwIiwgdGhlcmUgYXJlIGV4aXN0aW5nIHVzZSBjYXNlcyBmb3IgaW5kaWNhdGluZyB0 aGF0IGFuIE9UUA0KPiB3YXMgdXNlZC4gIEknbSBub3QgYXdhcmUgb2YgYW55IG9mIHRoZXNlIHVz ZSBjYXNlcyB3aGVyZSB0aGUNCj4gZGlzdGluY3Rpb24gYmV0d2VlbiBUT1RQIGFuZCBIT1RQIGlz IGltcG9ydGFudC4gIFRodXMsIGhhdmluZyAib3RwIg0KPiBub3cgbWFrZXMgc2Vuc2UsIHdoZXJl IGhhdmluZyAiaG90cCIgYW5kICJ0b3RwIiBub3cgZG9lc24ndC4NCj4gDQo+IFN0ZXBoZW4sIHRo aXMgbWF5IHNlZW0gbGlrZSBzcGxpdHRpbmcgaGFpcnMsIGJ1dCB0aGUgcmVnaXN0cnkNCj4gaW5z dHJ1Y3Rpb25zIGZvciAiU3BlY2lmaWNhdGlvbiBEb2N1bWVudChzKSIgYXJlIGFib3V0IGhhdmlu ZyBhDQo+IHJlZmVyZW5jZSBmb3IgdGhlIGRvY3VtZW50IHdoZXJlIHRoZSBBdXRoZW50aWNhdGlv biBNZXRob2QgUmVmZXJlbmNlDQo+IE5hbWUgKHN1Y2ggYXMgIm90cCIpIGlzIGRlZmluZWQuICBJ biBhbGwgY2FzZXMgZm9yIHRoZSBpbml0aWFsDQo+IHZhbHVlcywgdGhpcyBpcyB0aGUgUkZDLXRv LWJlLCBzbyB0aGUgcmVnaXN0cnkgaW5zdHJ1Y3Rpb25zIGFyZQ0KPiBzYXRpc2ZpZWQuICBJZiBz b21lb25lIHdlcmUsIGZvciBpbnN0YW5jZSwgdG8gZGVmaW5lIHRoZSBzdHJpbmcNCj4gImhvdHAi LCBpdCB3b3VsZCBiZSBpbmN1bWJlbnQgb24gdGhlIHBlcnNvbiByZXF1ZXN0aW5nIGl0cw0KPiBy ZWdpc3RyYXRpb24gdG8gcHJvdmlkZSBhIFVSTCB0byB0aGUgZG9jdW1lbnQgd2hlcmUgdGhlIHN0 cmluZyAiaG90cCINCj4gaXMgZGVmaW5lZC4gIEFsc28gaGF2aW5nIGEgcmVmZXJlbmNlIHRvIFJG QyA0MjI2IGluIHRoYXQgZG9jdW1lbnQNCj4gd291bGQgYmUgYSBnb29kIHRoaW5nLCBidXQgdGhh dCBpc24ndCB3aGF0IHRoZSByZWdpc3RyeSBpbnN0cnVjdGlvbnMNCj4gYXJlIGFib3V0Lg0KPiAN Cj4gQWxsIHRoYXQgc2FpZCwgSSBjYW4gbG9vayBhdCBhbHNvIGZpbmRpbmcgYXBwcm9wcmlhdGUg cmVmZXJlbmNlcyBmb3INCj4gdGhlIHJlbWFpbmluZyB2YWx1ZXMgdGhhdCBkb24ndCBjdXJyZW50 bHkgaGF2ZSB0aGVtLiAgKEFueW9uZSBnb3QgYQ0KPiBnb29kIHJlZmVyZW5jZSBmb3IgcGFzc3dv cmQgb3IgUElOIHRvIHN1Z2dlc3QsIGZvciBpbnN0YW5jZT8pDQo+IA0KPiAtLSBNaWtlDQo+IA0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBBbnRob255IE5hZGFsaW4gU2VudDog V2VkbmVzZGF5LA0KPiBGZWJydWFyeSAxLCAyMDE3IDQ6MTAgUE0gVG86IFN0ZXBoZW4gRmFycmVs bA0KPiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT47IE1pa2UgSm9uZXMNCj4gPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT47IGpvZWwgamFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT47IFRo ZQ0KPiBJRVNHIDxpZXNnQGlldGYub3JnPiBDYzogb2F1dGgtY2hhaXJzQGlldGYub3JnOw0KPiBk cmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnIFN1Ympl Y3Q6IFJFOg0KPiBbT0FVVEgtV0ddIFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mgb24NCj4gZHJh ZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTA1OiAod2l0aCBESVNDVVNTKQ0KPiANCj4gTklTVCBh c2tlZCBmb3IgdGhlIGFkZGl0aW9uIG9mIElSSVMgKGFzIHRoZXkgYXJlIHNlZWluZyBtb3JlIHVz ZSBvZg0KPiBJUklTIG92ZXIgcmV0aW5hIGR1ZSB0byB0aGUgYWNjdXJhY3kgb2YgaXJpcykgIGFz IHRoZXkgaGF2ZSBiZWVuDQo+IGRvaW5nIHNpZ25pZmljYW50IHRlc3Rpbmcgb24gdmFyaW91cyBp cmlzIGRldmljZXMgYW5kIGNvbnRpbnVlIHRvIGRvDQo+IHNvLCBoZXJlIGlzIGEgcmVwb3J0IHRo YXQgTklTVCByZWxlYXNlZA0KPiBodHRwOi8vMjAxMC0yMDE0LmNvbW1lcmNlLmdvdi9ibG9nLzIw MTIvMDQvMjMvbmlzdC1pcmlzLXJlY29nbml0aW9uLXJlcG9ydC1ldmFsdWF0ZXMtbmVlZGxlLWhh eXN0YWNrLXNlYXJjaC1jYXBhYmlsaXR5Lmh0bWwNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLSBGcm9tOiBTdGVwaGVuIEZhcnJlbGwNCj4gW21haWx0bzpzdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllXSBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEsIDIwMTcNCj4gMjoyNiBQ TSBUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgam9lbCBqYWVn Z2xpDQo+IDxqb2VsamFAYm9ndXMuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+IENjOg0K PiBvYXV0aC1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlc0BpZXRm Lm9yZzsNCj4gb2F1dGhAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU3RlcGhlbiBG YXJyZWxsJ3MgRGlzY3VzcyBvbg0KPiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6ICh3 aXRoIERJU0NVU1MpDQo+IA0KPiANCj4gSGkgTWlrZSwNCj4gDQo+IE9uIDAxLzAyLzE3IDE3OjAw LCBNaWtlIEpvbmVzIHdyb3RlOg0KPj4gVGhhbmtzIGZvciB0aGUgZGlzY3Vzc2lvbiwgU3RlcGhl bi4NCj4+IA0KPj4gVG8geW91ciBwb2ludCBhYm91dCAib3RwIiwgdGhlIHdvcmtpbmcgZ3JvdXAg ZGlzY3Vzc2VkIHRoaXMgdmVyeSANCj4+IHBvaW50LiAgVGhleSBleHBsaWNpdGx5IGRlY2lkZWQg bm90IHRvIGludHJvZHVjZSAiaG90cCIgYW5kICJ0b3RwIiANCj4+IGlkZW50aWZpZXJzIGJlY2F1 c2Ugbm8gb25lIGhhZCBhIHVzZSBjYXNlIGluIHdoaWNoIHRoZSBkaXN0aW5jdGlvbiANCj4+IG1h dHRlcmVkLg0KPiANCj4gVGhlbiBJJ20gbm90IGZvbGxvd2luZyB3aHkgYWRkaW5nICJvdHAiIHRv IHRoZSByZWdpc3RyeSBub3cgaXMgYSBnb29kDQo+IHBsYW4uDQo+IA0KPiBJZiB0aGVyZSdzIGEg dXNlLWNhc2Ugbm93LCB0aGVuIGFkZGluZyBhbiBlbnRyeSB3aXRoIGEgZ29vZCByZWZlcmVuY2UN Cj4gdG8gdGhlIHJlbGV2YW50IHNwZWMgc2VlbXMgcmlnaHQuDQo+IA0KPiBJZiB0aGVyZSdzIG5v IHVzZS1jYXNlIG5vdywgdGhlbiBub3QgYWRkaW5nIGl0IHRvIHRoZSByZWdpc3RyeSBzZWVtcw0K PiByaWdodC4gKE1lbnRpb25pbmcgaXQgYXMgYSBwb3NzaWJsZSBmdXR1cmUgZW50cnkgd291bGQg YmUgZmluZS4pDQo+IA0KPiBJIHRoaW5rIHRoZSBzYW1lIGxvZ2ljIHdvdWxkIGFwcGx5IGZvciBh bGwgdGhlIHZhbHVlcyB0aGF0IHRoaXMgc3BlYw0KPiBhZGRzIHRvIHRoZSByZWdpc3RyeS4gV2h5 IGlzIHRoYXQgd3Jvbmc/DQo+IA0KPj4gT3RoZXJzIGNhbiBjZXJ0YWlubHkgaW50cm9kdWNlIHRo b3NlIGlkZW50aWZpZXJzIGFuZCByZWdpc3RlciB0aGVtDQo+PiBpZiB0aGV5IGRvIGhhdmUgc3Vj aCBhIHVzZSBjYXNlLCBvbmNlIHRoZSByZWdpc3RyeSBoYXMgYmVlbg0KPj4gZXN0YWJsaXNoZWQu ICBCdXQgdGhlIHdvcmtpbmcgZ3JvdXAgd2FudGVkIHRvIGJlIGNvbnNlcnZhdGl2ZSBhYm91dA0K Pj4gdGhlIGlkZW50aWZpZXJzIGludHJvZHVjZWQgdG8gcHJpbWUgdGhlIHJlZ2lzdHJ5LCBhbmQg dGhpcyBpcyBzdWNoDQo+PiBhIGNhc2UuDQo+PiANCj4+IFdoYXQgaWRlbnRpZmllcnMgdG8gdXNl IGFuZCByZWdpc3RlciB3aWxsIGFsd2F5cyBiZSBhIGJhbGFuY2luZw0KPj4gYWN0LiBZb3Ugd2Fu dCB0byBiZSBhcyBzcGVjaWZpYyBhcyBuZWNlc3NhcnkgdG8gYWRkIHByYWN0aWNhbCBhbmQNCj4+ IHVzYWJsZSB2YWx1ZSwgYnV0IG5vdCBzbyBzcGVjaWZpYyBhcyB0byBtYWtlIHRoaW5ncyB1bm5l Y2Vzc2FyaWx5DQo+PiBicml0dGxlLg0KPiANCj4gRWguLi4gZG9uJ3Qgd2Ugd2FudCBpbnRlcm9w PyBJc24ndCB0aGF0IHRoZSBwcmltYXJ5IGdvYWwgaGVyZT8NCj4gDQo+PiBXaGlsZSBzb21lIG1p Z2h0IHNheSB0aGVyZSdzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHNlcmlhbCBudW1iZXIgDQo+PiBy YW5nZXMgb2YgcGFydGljdWxhciBhdXRoZW50aWNhdGlvbiBkZXZpY2VzLCBnb2luZyB0aGVyZSBp cw0KPj4gY2xlYXJseSBpbiB0aGUgd2VlZHMuICBPbiB0aGUgb3RoZXIgaGFuZCwgd2hpbGUgdGhl cmUgdXNlZCB0byBiZSBhbg0KPj4gImV5ZSIgaWRlbnRpZmllciwgRWxhaW5lIE5ld3RvbiBvZiBO SVNUIHBvaW50ZWQgb3V0IHRoYXQgdGhlcmUgYXJlIA0KPj4gc2lnbmlmaWNhbnQgZGlmZmVyZW5j ZXMgYmV0d2VlbiByZXRpbmEgYW5kIGlyaXMgbWF0Y2hpbmcsIHNvICJleWUiIA0KPj4gd2FzIHJl cGxhY2VkIHdpdGggInJldGluYSIgYW5kICJpcmlzIi4gIENvbW1vbiBzZW5zZSBpbmZvcm1lZCBi eSANCj4+IGFjdHVhbCBkYXRhIGlzIHRoZSBrZXkgaGVyZS4NCj4gDQo+IFRoYXQncyBhbm90aGVy IGdvb2QgZXhhbXBsZS4gVGhlcmUncyBubyByZWZlcmVuY2UgZm9yICJpcmlzLiIgSWYgdGhhdA0K PiBpcyB1c2VkIGluIHNvbWUgcHJvdG9jb2wsIHRoZW4gd2hhdCBmb3JtYXQocykgYXJlIGV4cGVj dGVkIHRvIGJlDQo+IHN1cHBvcnRlZD8gV2hlcmUgZG8gSSBmaW5kIHRoYXQgc3BlYz8gSWYgd2Ug Y2FuIGFuc3dlciB0aGF0LCB0aGVuDQo+IGdyZWF0LCBsZXQncyBhZGQgdGhlIGRldGFpbHMuIElm IG5vdCwgdGhlbiBJJ2Qgc3VnZ2VzdCB3ZSBvbWl0ICJpcmlzIg0KPiBhbmQgbGVhdmUgaXQgJ3Rp bGwgbGF0ZXIgdG8gYWRkIGFuIGVudHJ5IGZvciB0aGF0LiBBbmQgYWdhaW4sDQo+IGluY2x1ZGlu ZyB0ZXh0IHdpdGggImlyaXMiIGFzIGFuIGV4YW1wbGUgaXMganVzdCBmaW5lLCBhbGwgSSdtIGFz a2luZw0KPiBpcyB0aGF0IHdlIG9ubHkgYWRkIHRoZSByZWdpc3RyeSBlbnRyeSBpZiB3ZSBjYW4g bWVldCB0aGUgc2FtZSBiYXINCj4gdGhhdCB3ZSdyZSBhc2tpbmcgdGhlIERFIHRvIGltcG9zZSBv biBsYXRlciBhZGRpdGlvbnMuDQo+IA0KPiBBbmQgdGhlIHNhbWUgZm9yIGFsbCB0aGUgb3RoZXJz Li4uDQo+IA0KPiBDaGVlcnMsIFMuDQo+IA0KPiANCj4+IA0KPj4gVGhlIHBvaW50IG9mIHRoZSBy ZWdpc3RyeSByZXF1aXJpbmcgYSBzcGVjaWZpY2F0aW9uIHJlZmVyZW5jZSBpcw0KPj4gc28gcGVv cGxlIHVzaW5nIHRoZSByZWdpc3RyeSBjYW4gdGVsbCB3aGVyZSB0aGUgaWRlbnRpZmllciBpcw0K Pj4gZGVmaW5lZC4gRm9yIGFsbCB0aGUgaW5pdGlhbCB2YWx1ZXMsIHRoYXQgcmVxdWlyZW1lbnQg aXMgc2F0aXNmaWVkLA0KPj4gc2luY2UgdGhlIHJlZmVyZW5jZSB3aWxsIGJlIHRvIHRoZSBuZXcg UkZDLiAgSSB0aGluayB0aGF0IGFsaWducw0KPj4gd2l0aCB0aGUgcG9pbnQgdGhhdCBKb2VsIHdh cyBtYWtpbmcuDQo+PiANCj4+IFlvdXIgdGhvdWdodHM/DQo+PiANCj4+IC0tIE1pa2UNCj4+IA0K Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogT0F1dGggDQo+PiBbbWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwgU2VudDog DQo+PiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEsIDIwMTcgNzowMyBBTSBUbzogam9lbCBqYWVnZ2xp IA0KPj4gPGpvZWxqYUBib2d1cy5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4gQ2M6IA0K Pj4gb2F1dGgtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXNAaWV0 Zi5vcmc7IA0KPj4gb2F1dGhAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU3RlcGhl biBGYXJyZWxsJ3MgRGlzY3Vzcw0KPj4gb24gZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTA1 OiAod2l0aCBESVNDVVNTKQ0KPj4gDQo+PiANCj4+IA0KPj4gT24gMDEvMDIvMTcgMTQ6NTgsIGpv ZWwgamFlZ2dsaSB3cm90ZToNCj4+PiBPbiAxLzMxLzE3IDg6MjYgQU0sIFN0ZXBoZW4gRmFycmVs bCB3cm90ZToNCj4+Pj4gU3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcg YmFsbG90IHBvc2l0aW9uIGZvciANCj4+Pj4gZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTA1 OiBEaXNjdXNzDQo+Pj4+IA0KPj4+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBz dWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseQ0KPj4+PiB0byBhbGwgZW1haWwgYWRkcmVzc2Vz IGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsDQo+Pj4+IGZyZWUgdG8gY3V0 IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+Pj4+IA0KPj4+PiANCj4+ Pj4gUGxlYXNlIHJlZmVyIHRvIA0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRl bWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwgZm9yIA0KPj4+PiBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+Pj4+IA0KPj4+PiANCj4+ Pj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBi ZSBmb3VuZCANCj4+Pj4gaGVyZTogDQo+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlcy8NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+ Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+Pj4+DQo+Pj4+DQo+DQo+Pj4+IA0KLQ0KPj4+PiBESVNDVVNTOiAN Cj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4+DQo+Pj4+DQo+DQo+Pj4+IA0KLQ0KPj4+PiANCj4+Pj4g VGhpcyBzcGVjaWZpY2F0aW9uIHNlZW1zIHRvIG1lIHRvIGJyZWFrIGl0J3Mgb3duIHJ1bGVzLiBZ b3UNCj4+Pj4gc3RhdGUgdGhhdCByZWdpc3RyYXRpb25zIHNob3VsZCBpbmNsdWRlIGEgcmVmZXJl bmNlIHRvIGENCj4+Pj4gc3BlY2lmaWNhdGlvbiB0byBpbXByb3ZlIGludGVyb3AuIEFuZCB5ZXQs IGZvciB0aGUgc3RyaW5ncw0KPj4+PiBhZGRlZCBoZXJlIChlLmcuIG90cCkgeW91IGRvbid0IGRv IHRoYXQgKHJlZmVycmluZyB0byBzZWN0aW9uIDINCj4+Pj4gd2lsbCBub3QgaW1wcm92ZSBpbnRl cm9wKSBhbmQgdGhlcmUgYXJlIGRpZmZlcmVudCB3YXlzIGluIHdoaWNoDQo+Pj4+IG1hbnkgb2Yg dGhlIG1ldGhvZHMgaW4gc2VjdGlvbiAyIGNhbiBiZSBkb25lLiBTbyBJIHRoaW5rIHlvdQ0KPj4+ PiBuZWVkIHRvIGFkZCBhIGJ1bmNoIG1vcmUgcmVmZXJlbmNlcy4NCj4+PiANCj4+PiBOb3QgY2xl YXIgdG8gbWUgdGhhdCB0aGUgZG9jdW1lbnQgY3JlYXRpbmcgdGhlIHJlZ2lzdHJ5IG5lZWRzIHRv DQo+Pj4gIGFkaGVyZSB0byB0aGUgcnVsZXMgZm9yIGZ1cnRoZXIgYWxsb2NhdGlvbnMgaW4gb3Jk ZXIgdG8NCj4+PiBwcmVwb3VsYXRlIHRoZSByZWdpc3RyeS4gdGhhdCBpcyBwZXJoYXBzIGFuIGFw cGVhbCB0byBmdXR1cmUNCj4+PiBjb25zaXN0ZW5jeS4NCj4+IA0KPj4gU3VyZSAtIEknbSBhbGwg Zm9yIGEgc21hdHRlcmluZyBvZiBpbmNvbnNpc3RlbmN5Oi0pDQo+PiANCj4+IEJ1dCBJIHRoaW5r IHRoZSBsYWNrIG9mIHNwZWNzIGluIHNvbWUgb2YgdGhlc2UgY2FzZXMgY291bGQgaW1wYWN0DQo+ PiBvbiBpbnRlcm9wLCBlLmcuIGluIHRoZSBvdHAgY2FzZSwgdGhleSBxdW90ZSB0d28gUkZDcyBh bmQgeWV0IG9ubHkNCj4+IGhhdmUgb25lIHZhbHVlLiBUaGF0IHNlZW1zIGEgYml0IGJyb2tlbiB0 byBtZSwgc28gdGhlIGRpc2N1c3MgaXNuJ3QNCj4+IHJlYWxseSBhYm91dCB0aGUgZm9ybWFsaXNt Lg0KPj4gDQo+PiBTLg0KPj4gDQo+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+PiANCj4+PiAN Cj4+IA0KPiANCg0K From nobody Wed Feb 1 16:28:56 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72011295EB; Wed, 1 Feb 2017 16:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id easI35-pJH2N; Wed, 1 Feb 2017 16:28:52 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0111.outbound.protection.outlook.com [104.47.42.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CABE129615; Wed, 1 Feb 2017 16:28:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uzwyGEnuLIHEbrl5pM1uK+WtRg5oJPC+cegg0sTSVmk=; b=Ep+qucdDH2dZVBlHNz+VTevr56Z4brXdmgUPGo/Y67T+KfMC+zkb5BP3rQJJsYpDSt7w7NCfeskRbPLpvjeHuMuloGXHjRRj11pRg+wtlX9hGIpkUkM2p+JKYQWS1Xl4UOfVJeZphsNLn4Lg55tiP5CM5iLbv/WtrZOB/4aQuKY= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BLUPR0301MB2017.namprd03.prod.outlook.com (10.164.22.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 00:28:50 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0874.021; Thu, 2 Feb 2017 00:28:49 +0000 From: Mike Jones To: Anthony Nadalin , Stephen Farrell , joel jaeggli , The IESG Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) Thread-Index: AQHSe97H5hXZpqeBE0CT6lHMY4yQFKFUP6sAgAABIQCAAB5D0IAAXXiAgAAdOACAAABqIIAAA2uAgAAA3wCAAAAzAA== Date: Thu, 2 Feb 2017 00:28:49 +0000 Message-ID: References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> <268ffcf0-2f90-049e-1a3c-03b39d62c338@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:c::388] x-ms-office365-filtering-correlation-id: 0f0e51b9-979d-4b09-5834-08d44b02756e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BLUPR0301MB2017; x-microsoft-exchange-diagnostics: 1; BLUPR0301MB2017; 7:jGcChVwOocypvTPFxj63CZ7GXD7Q93+73XFi6NRHCHNm+Hj4sNKYNLRUuUyRz8eGWAWwf8xpXugnRr+Nr1fnPMANUhkfSC68JUxyES0mF6woxQag9VBbux97D/2nOOT1i5m9xl4lTCas/GZ4Ofz6fuWA3hlSjljwN+IoVx7iUAdzMLar/fyOqBLLbiuU33Gq3Y5/BHEQk9C7aRGTKbyTjWq7Ym7lRiURp7wOBGG6LRXHyXs9h+2jfJVy8fTahfQefnCeBXoV076ajSaRPRE3yPvKsdP0dUZ34LzWHUqgZAAC9bkxYG0CB3XmWSKWBqb4flkoaAT5bpFXP5/yQdDl7X9NQQcmx9jeuHPwAPpgHsHrhqmmJpcp+AqVQRG1KCsksHLXS5KXaTRpWoJmbFRSVQWRHdCXQy5+GyO/XkbEpcuRYNVyHABW38LroI8orNXGBHedTr50mHTh+gkzUfBBJ2XpTeyFS09pDO14aEW5ON0pDjoeL9z4rEma5uBhmihWhx0ZHrP+2IGBFNvENp9/U1us/3esEoin8pqZ19j0A3U8ygN7NMXsPjcO90exASHS x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(120809045254105)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558025)(20161123560025)(6072148); SRVR:BLUPR0301MB2017; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0301MB2017; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39450400003)(39410400002)(39840400002)(39850400002)(13464003)(199003)(40224003)(51444003)(51914003)(377454003)(189002)(24454002)(2950100002)(101416001)(6436002)(77096006)(38730400001)(50986999)(305945005)(7696004)(54356999)(76176999)(33656002)(7736002)(9686003)(74316002)(86362001)(68736007)(6506006)(229853002)(8676002)(5005710100001)(966004)(3900700001)(8990500004)(8936002)(86612001)(10290500002)(3660700001)(53936002)(81156014)(5660300001)(551544002)(81166006)(10090500001)(102836003)(106356001)(3280700002)(2906002)(106116001)(6116002)(93886004)(2421001)(1511001)(92566002)(4326007)(5001770100001)(122556002)(97736004)(105586002)(189998001)(230783001)(55016002)(25786008)(54906002)(99286003)(6306002)(2900100001)(2561002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0301MB2017; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 00:28:49.5924 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0301MB2017 Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:28:56 -0000 VGhlIG90aGVyIGNhc2Ugb2Yga25vd24gaW50ZXJvcCB0ZXN0aW5nIG9mICJhbXIiIHZhbHVlcyBp cyBmb3IgTU9EUk5BIChPcGVuSUQgQ29ubmVjdCBNb2JpbGUgUHJvZmlsZSkgaW1wbGVtZW50YXRp b25zLiAgVGhlcmUncyBhIHJlZmVyZW5jZSB0byBpdHMgdXNlIG9mICJhbXIiIHZhbHVlcyBpbiB0 aGUgc3BlYy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFudGhvbnkgTmFk YWxpbiANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMSwgMjAxNyA0OjI3IFBNDQpUbzogU3Rl cGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPjsgTWlrZSBKb25lcyA8TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgam9lbCBqYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29t PjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogb2F1dGgtY2hhaXJzQGlldGYub3JnOyBk cmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogW09BVVRILVdHXSBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIG9uIGRyYWZ0LWll dGYtb2F1dGgtYW1yLXZhbHVlcy0wNTogKHdpdGggRElTQ1VTUykNCg0KV2UgaGF2ZSBpbnRlcm9w ZWQgYmV0d2VlbiBGSURPIGF1dGhlbnRpY2F0b3JzIHZlbmRvcnMgYW5kIFdpbmRvd3MgSGVsbG8N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZXBoZW4gRmFycmVsbCBbbWFp bHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdIA0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFy eSAxLCAyMDE3IDQ6MjQgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20+OyBBbnRob255IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT47IGpvZWwgamFl Z2dsaSA8am9lbGphQGJvZ3VzLmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IG9h dXRoLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzQGlldGYub3Jn OyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU3RlcGhlbiBGYXJyZWxs J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6ICh3aXRoIERJU0NV U1MpDQoNCg0KDQpPbiAwMi8wMi8xNyAwMDoyMSwgTWlrZSBKb25lcyB3cm90ZToNCj4gVGhhbmtz LCBUb255LiAgSSBjYW4gYWRkIHRoYXQgcmVmZXJlbmNlLg0KPiANCj4gU3RlcGhlbiwgdGhlIHNl dHMgb2YgaW5pdGlhbCB2YWx1ZXMgd2VyZSBjaG9zZW4gZnJvbSB0aG9zZSB1c2VkIGluDQo+IHBy YWN0aWNlIGJ5IE1pY3Jvc29mdCBhbmQgR29vZ2xlIGluIHJlYWwgZGVwbG95bWVudHMuDQoNCkdl bnVpbmUgcXVlc3Rpb25zOiBkbyB5b3UgYWltIHRvIGhhdmUgaW50ZXJvcCBiZXR3ZWVuIHRob3Nl DQpkZXBsb3ltZW50cz8gV2hhdCBpZiBJIHdhbnRlZCB0byB3cml0ZSBjb2RlIHRoYXQnZCBpbnRl cm9wDQp3aXRoIG1zZnQgb3IgZ29vZ2xlPw0KDQpTLg0KDQo+IA0KPiBBYm91dCAib3RwIiwgdGhl cmUgYXJlIGV4aXN0aW5nIHVzZSBjYXNlcyBmb3IgaW5kaWNhdGluZyB0aGF0IGFuIE9UUA0KPiB3 YXMgdXNlZC4gIEknbSBub3QgYXdhcmUgb2YgYW55IG9mIHRoZXNlIHVzZSBjYXNlcyB3aGVyZSB0 aGUNCj4gZGlzdGluY3Rpb24gYmV0d2VlbiBUT1RQIGFuZCBIT1RQIGlzIGltcG9ydGFudC4gIFRo dXMsIGhhdmluZyAib3RwIg0KPiBub3cgbWFrZXMgc2Vuc2UsIHdoZXJlIGhhdmluZyAiaG90cCIg YW5kICJ0b3RwIiBub3cgZG9lc24ndC4NCj4gDQo+IFN0ZXBoZW4sIHRoaXMgbWF5IHNlZW0gbGlr ZSBzcGxpdHRpbmcgaGFpcnMsIGJ1dCB0aGUgcmVnaXN0cnkNCj4gaW5zdHJ1Y3Rpb25zIGZvciAi U3BlY2lmaWNhdGlvbiBEb2N1bWVudChzKSIgYXJlIGFib3V0IGhhdmluZyBhDQo+IHJlZmVyZW5j ZSBmb3IgdGhlIGRvY3VtZW50IHdoZXJlIHRoZSBBdXRoZW50aWNhdGlvbiBNZXRob2QgUmVmZXJl bmNlDQo+IE5hbWUgKHN1Y2ggYXMgIm90cCIpIGlzIGRlZmluZWQuICBJbiBhbGwgY2FzZXMgZm9y IHRoZSBpbml0aWFsDQo+IHZhbHVlcywgdGhpcyBpcyB0aGUgUkZDLXRvLWJlLCBzbyB0aGUgcmVn aXN0cnkgaW5zdHJ1Y3Rpb25zIGFyZQ0KPiBzYXRpc2ZpZWQuICBJZiBzb21lb25lIHdlcmUsIGZv ciBpbnN0YW5jZSwgdG8gZGVmaW5lIHRoZSBzdHJpbmcNCj4gImhvdHAiLCBpdCB3b3VsZCBiZSBp bmN1bWJlbnQgb24gdGhlIHBlcnNvbiByZXF1ZXN0aW5nIGl0cw0KPiByZWdpc3RyYXRpb24gdG8g cHJvdmlkZSBhIFVSTCB0byB0aGUgZG9jdW1lbnQgd2hlcmUgdGhlIHN0cmluZyAiaG90cCINCj4g aXMgZGVmaW5lZC4gIEFsc28gaGF2aW5nIGEgcmVmZXJlbmNlIHRvIFJGQyA0MjI2IGluIHRoYXQg ZG9jdW1lbnQNCj4gd291bGQgYmUgYSBnb29kIHRoaW5nLCBidXQgdGhhdCBpc24ndCB3aGF0IHRo ZSByZWdpc3RyeSBpbnN0cnVjdGlvbnMNCj4gYXJlIGFib3V0Lg0KPiANCj4gQWxsIHRoYXQgc2Fp ZCwgSSBjYW4gbG9vayBhdCBhbHNvIGZpbmRpbmcgYXBwcm9wcmlhdGUgcmVmZXJlbmNlcyBmb3IN Cj4gdGhlIHJlbWFpbmluZyB2YWx1ZXMgdGhhdCBkb24ndCBjdXJyZW50bHkgaGF2ZSB0aGVtLiAg KEFueW9uZSBnb3QgYQ0KPiBnb29kIHJlZmVyZW5jZSBmb3IgcGFzc3dvcmQgb3IgUElOIHRvIHN1 Z2dlc3QsIGZvciBpbnN0YW5jZT8pDQo+IA0KPiAtLSBNaWtlDQo+IA0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLSBGcm9tOiBBbnRob255IE5hZGFsaW4gU2VudDogV2VkbmVzZGF5LA0KPiBG ZWJydWFyeSAxLCAyMDE3IDQ6MTAgUE0gVG86IFN0ZXBoZW4gRmFycmVsbA0KPiA8c3RlcGhlbi5m YXJyZWxsQGNzLnRjZC5pZT47IE1pa2UgSm9uZXMNCj4gPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT47IGpvZWwgamFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbT47IFRoZQ0KPiBJRVNHIDxpZXNn QGlldGYub3JnPiBDYzogb2F1dGgtY2hhaXJzQGlldGYub3JnOw0KPiBkcmFmdC1pZXRmLW9hdXRo LWFtci12YWx1ZXNAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnIFN1YmplY3Q6IFJFOg0KPiBbT0FV VEgtV0ddIFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mgb24NCj4gZHJhZnQtaWV0Zi1vYXV0aC1h bXItdmFsdWVzLTA1OiAod2l0aCBESVNDVVNTKQ0KPiANCj4gTklTVCBhc2tlZCBmb3IgdGhlIGFk ZGl0aW9uIG9mIElSSVMgKGFzIHRoZXkgYXJlIHNlZWluZyBtb3JlIHVzZSBvZg0KPiBJUklTIG92 ZXIgcmV0aW5hIGR1ZSB0byB0aGUgYWNjdXJhY3kgb2YgaXJpcykgIGFzIHRoZXkgaGF2ZSBiZWVu DQo+IGRvaW5nIHNpZ25pZmljYW50IHRlc3Rpbmcgb24gdmFyaW91cyBpcmlzIGRldmljZXMgYW5k IGNvbnRpbnVlIHRvIGRvDQo+IHNvLCBoZXJlIGlzIGEgcmVwb3J0IHRoYXQgTklTVCByZWxlYXNl ZA0KPiBodHRwOi8vMjAxMC0yMDE0LmNvbW1lcmNlLmdvdi9ibG9nLzIwMTIvMDQvMjMvbmlzdC1p cmlzLXJlY29nbml0aW9uLXJlcG9ydC1ldmFsdWF0ZXMtbmVlZGxlLWhheXN0YWNrLXNlYXJjaC1j YXBhYmlsaXR5Lmh0bWwNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9t OiBTdGVwaGVuIEZhcnJlbGwNCj4gW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXSBT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEsIDIwMTcNCj4gMjoyNiBQTSBUbzogTWlrZSBKb25l cyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgam9lbCBqYWVnZ2xpDQo+IDxqb2VsamFA Ym9ndXMuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+IENjOg0KPiBvYXV0aC1jaGFpcnNA aWV0Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlc0BpZXRmLm9yZzsNCj4gb2F1dGhA aWV0Zi5vcmcgU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3Vz cyBvbg0KPiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6ICh3aXRoIERJU0NVU1MpDQo+ IA0KPiANCj4gSGkgTWlrZSwNCj4gDQo+IE9uIDAxLzAyLzE3IDE3OjAwLCBNaWtlIEpvbmVzIHdy b3RlOg0KPj4gVGhhbmtzIGZvciB0aGUgZGlzY3Vzc2lvbiwgU3RlcGhlbi4NCj4+IA0KPj4gVG8g eW91ciBwb2ludCBhYm91dCAib3RwIiwgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzY3Vzc2VkIHRoaXMg dmVyeSANCj4+IHBvaW50LiAgVGhleSBleHBsaWNpdGx5IGRlY2lkZWQgbm90IHRvIGludHJvZHVj ZSAiaG90cCIgYW5kICJ0b3RwIiANCj4+IGlkZW50aWZpZXJzIGJlY2F1c2Ugbm8gb25lIGhhZCBh IHVzZSBjYXNlIGluIHdoaWNoIHRoZSBkaXN0aW5jdGlvbiANCj4+IG1hdHRlcmVkLg0KPiANCj4g VGhlbiBJJ20gbm90IGZvbGxvd2luZyB3aHkgYWRkaW5nICJvdHAiIHRvIHRoZSByZWdpc3RyeSBu b3cgaXMgYSBnb29kDQo+IHBsYW4uDQo+IA0KPiBJZiB0aGVyZSdzIGEgdXNlLWNhc2Ugbm93LCB0 aGVuIGFkZGluZyBhbiBlbnRyeSB3aXRoIGEgZ29vZCByZWZlcmVuY2UNCj4gdG8gdGhlIHJlbGV2 YW50IHNwZWMgc2VlbXMgcmlnaHQuDQo+IA0KPiBJZiB0aGVyZSdzIG5vIHVzZS1jYXNlIG5vdywg dGhlbiBub3QgYWRkaW5nIGl0IHRvIHRoZSByZWdpc3RyeSBzZWVtcw0KPiByaWdodC4gKE1lbnRp b25pbmcgaXQgYXMgYSBwb3NzaWJsZSBmdXR1cmUgZW50cnkgd291bGQgYmUgZmluZS4pDQo+IA0K PiBJIHRoaW5rIHRoZSBzYW1lIGxvZ2ljIHdvdWxkIGFwcGx5IGZvciBhbGwgdGhlIHZhbHVlcyB0 aGF0IHRoaXMgc3BlYw0KPiBhZGRzIHRvIHRoZSByZWdpc3RyeS4gV2h5IGlzIHRoYXQgd3Jvbmc/ DQo+IA0KPj4gT3RoZXJzIGNhbiBjZXJ0YWlubHkgaW50cm9kdWNlIHRob3NlIGlkZW50aWZpZXJz IGFuZCByZWdpc3RlciB0aGVtDQo+PiBpZiB0aGV5IGRvIGhhdmUgc3VjaCBhIHVzZSBjYXNlLCBv bmNlIHRoZSByZWdpc3RyeSBoYXMgYmVlbg0KPj4gZXN0YWJsaXNoZWQuICBCdXQgdGhlIHdvcmtp bmcgZ3JvdXAgd2FudGVkIHRvIGJlIGNvbnNlcnZhdGl2ZSBhYm91dA0KPj4gdGhlIGlkZW50aWZp ZXJzIGludHJvZHVjZWQgdG8gcHJpbWUgdGhlIHJlZ2lzdHJ5LCBhbmQgdGhpcyBpcyBzdWNoDQo+ PiBhIGNhc2UuDQo+PiANCj4+IFdoYXQgaWRlbnRpZmllcnMgdG8gdXNlIGFuZCByZWdpc3RlciB3 aWxsIGFsd2F5cyBiZSBhIGJhbGFuY2luZw0KPj4gYWN0LiBZb3Ugd2FudCB0byBiZSBhcyBzcGVj aWZpYyBhcyBuZWNlc3NhcnkgdG8gYWRkIHByYWN0aWNhbCBhbmQNCj4+IHVzYWJsZSB2YWx1ZSwg YnV0IG5vdCBzbyBzcGVjaWZpYyBhcyB0byBtYWtlIHRoaW5ncyB1bm5lY2Vzc2FyaWx5DQo+PiBi cml0dGxlLg0KPiANCj4gRWguLi4gZG9uJ3Qgd2Ugd2FudCBpbnRlcm9wPyBJc24ndCB0aGF0IHRo ZSBwcmltYXJ5IGdvYWwgaGVyZT8NCj4gDQo+PiBXaGlsZSBzb21lIG1pZ2h0IHNheSB0aGVyZSdz IGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHNlcmlhbCBudW1iZXIgDQo+PiByYW5nZXMgb2YgcGFydGlj dWxhciBhdXRoZW50aWNhdGlvbiBkZXZpY2VzLCBnb2luZyB0aGVyZSBpcw0KPj4gY2xlYXJseSBp biB0aGUgd2VlZHMuICBPbiB0aGUgb3RoZXIgaGFuZCwgd2hpbGUgdGhlcmUgdXNlZCB0byBiZSBh bg0KPj4gImV5ZSIgaWRlbnRpZmllciwgRWxhaW5lIE5ld3RvbiBvZiBOSVNUIHBvaW50ZWQgb3V0 IHRoYXQgdGhlcmUgYXJlIA0KPj4gc2lnbmlmaWNhbnQgZGlmZmVyZW5jZXMgYmV0d2VlbiByZXRp bmEgYW5kIGlyaXMgbWF0Y2hpbmcsIHNvICJleWUiIA0KPj4gd2FzIHJlcGxhY2VkIHdpdGggInJl dGluYSIgYW5kICJpcmlzIi4gIENvbW1vbiBzZW5zZSBpbmZvcm1lZCBieSANCj4+IGFjdHVhbCBk YXRhIGlzIHRoZSBrZXkgaGVyZS4NCj4gDQo+IFRoYXQncyBhbm90aGVyIGdvb2QgZXhhbXBsZS4g VGhlcmUncyBubyByZWZlcmVuY2UgZm9yICJpcmlzLiIgSWYgdGhhdA0KPiBpcyB1c2VkIGluIHNv bWUgcHJvdG9jb2wsIHRoZW4gd2hhdCBmb3JtYXQocykgYXJlIGV4cGVjdGVkIHRvIGJlDQo+IHN1 cHBvcnRlZD8gV2hlcmUgZG8gSSBmaW5kIHRoYXQgc3BlYz8gSWYgd2UgY2FuIGFuc3dlciB0aGF0 LCB0aGVuDQo+IGdyZWF0LCBsZXQncyBhZGQgdGhlIGRldGFpbHMuIElmIG5vdCwgdGhlbiBJJ2Qg c3VnZ2VzdCB3ZSBvbWl0ICJpcmlzIg0KPiBhbmQgbGVhdmUgaXQgJ3RpbGwgbGF0ZXIgdG8gYWRk IGFuIGVudHJ5IGZvciB0aGF0LiBBbmQgYWdhaW4sDQo+IGluY2x1ZGluZyB0ZXh0IHdpdGggImly aXMiIGFzIGFuIGV4YW1wbGUgaXMganVzdCBmaW5lLCBhbGwgSSdtIGFza2luZw0KPiBpcyB0aGF0 IHdlIG9ubHkgYWRkIHRoZSByZWdpc3RyeSBlbnRyeSBpZiB3ZSBjYW4gbWVldCB0aGUgc2FtZSBi YXINCj4gdGhhdCB3ZSdyZSBhc2tpbmcgdGhlIERFIHRvIGltcG9zZSBvbiBsYXRlciBhZGRpdGlv bnMuDQo+IA0KPiBBbmQgdGhlIHNhbWUgZm9yIGFsbCB0aGUgb3RoZXJzLi4uDQo+IA0KPiBDaGVl cnMsIFMuDQo+IA0KPiANCj4+IA0KPj4gVGhlIHBvaW50IG9mIHRoZSByZWdpc3RyeSByZXF1aXJp bmcgYSBzcGVjaWZpY2F0aW9uIHJlZmVyZW5jZSBpcw0KPj4gc28gcGVvcGxlIHVzaW5nIHRoZSBy ZWdpc3RyeSBjYW4gdGVsbCB3aGVyZSB0aGUgaWRlbnRpZmllciBpcw0KPj4gZGVmaW5lZC4gRm9y IGFsbCB0aGUgaW5pdGlhbCB2YWx1ZXMsIHRoYXQgcmVxdWlyZW1lbnQgaXMgc2F0aXNmaWVkLA0K Pj4gc2luY2UgdGhlIHJlZmVyZW5jZSB3aWxsIGJlIHRvIHRoZSBuZXcgUkZDLiAgSSB0aGluayB0 aGF0IGFsaWducw0KPj4gd2l0aCB0aGUgcG9pbnQgdGhhdCBKb2VsIHdhcyBtYWtpbmcuDQo+PiAN Cj4+IFlvdXIgdGhvdWdodHM/DQo+PiANCj4+IC0tIE1pa2UNCj4+IA0KPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0gRnJvbTogT0F1dGggDQo+PiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwgU2VudDogDQo+PiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDEsIDIwMTcgNzowMyBBTSBUbzogam9lbCBqYWVnZ2xpIA0KPj4gPGpvZWxqYUBi b2d1cy5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4gQ2M6IA0KPj4gb2F1dGgtY2hhaXJz QGlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7IA0KPj4gb2F1 dGhAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU3RlcGhlbiBGYXJyZWxsJ3MgRGlz Y3Vzcw0KPj4gb24gZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTA1OiAod2l0aCBESVNDVVNT KQ0KPj4gDQo+PiANCj4+IA0KPj4gT24gMDEvMDIvMTcgMTQ6NTgsIGpvZWwgamFlZ2dsaSB3cm90 ZToNCj4+PiBPbiAxLzMxLzE3IDg6MjYgQU0sIFN0ZXBoZW4gRmFycmVsbCB3cm90ZToNCj4+Pj4g U3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9u IGZvciANCj4+Pj4gZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTA1OiBEaXNjdXNzDQo+Pj4+ IA0KPj4+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50 YWN0IGFuZCByZXBseQ0KPj4+PiB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsDQo+Pj4+IGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0 b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+Pj4+IA0KPj4+PiANCj4+Pj4gUGxlYXNlIHJlZmVy IHRvIA0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNy aXRlcmlhLmh0bWwgZm9yIA0KPj4+PiBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VT UyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+Pj4+IA0KPj4+PiANCj4+Pj4gVGhlIGRvY3VtZW50 LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCANCj4+Pj4g aGVyZTogDQo+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt b2F1dGgtYW1yLXZhbHVlcy8NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4+DQo+Pj4+DQo+DQo+Pj4+IA0KLQ0KPj4+PiBESVNDVVNTOiANCj4+Pj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+Pj4+DQo+Pj4+DQo+DQo+Pj4+IA0KLQ0KPj4+PiANCj4+Pj4gVGhpcyBzcGVjaWZpY2F0 aW9uIHNlZW1zIHRvIG1lIHRvIGJyZWFrIGl0J3Mgb3duIHJ1bGVzLiBZb3UNCj4+Pj4gc3RhdGUg dGhhdCByZWdpc3RyYXRpb25zIHNob3VsZCBpbmNsdWRlIGEgcmVmZXJlbmNlIHRvIGENCj4+Pj4g c3BlY2lmaWNhdGlvbiB0byBpbXByb3ZlIGludGVyb3AuIEFuZCB5ZXQsIGZvciB0aGUgc3RyaW5n cw0KPj4+PiBhZGRlZCBoZXJlIChlLmcuIG90cCkgeW91IGRvbid0IGRvIHRoYXQgKHJlZmVycmlu ZyB0byBzZWN0aW9uIDINCj4+Pj4gd2lsbCBub3QgaW1wcm92ZSBpbnRlcm9wKSBhbmQgdGhlcmUg YXJlIGRpZmZlcmVudCB3YXlzIGluIHdoaWNoDQo+Pj4+IG1hbnkgb2YgdGhlIG1ldGhvZHMgaW4g c2VjdGlvbiAyIGNhbiBiZSBkb25lLiBTbyBJIHRoaW5rIHlvdQ0KPj4+PiBuZWVkIHRvIGFkZCBh IGJ1bmNoIG1vcmUgcmVmZXJlbmNlcy4NCj4+PiANCj4+PiBOb3QgY2xlYXIgdG8gbWUgdGhhdCB0 aGUgZG9jdW1lbnQgY3JlYXRpbmcgdGhlIHJlZ2lzdHJ5IG5lZWRzIHRvDQo+Pj4gIGFkaGVyZSB0 byB0aGUgcnVsZXMgZm9yIGZ1cnRoZXIgYWxsb2NhdGlvbnMgaW4gb3JkZXIgdG8NCj4+PiBwcmVw b3VsYXRlIHRoZSByZWdpc3RyeS4gdGhhdCBpcyBwZXJoYXBzIGFuIGFwcGVhbCB0byBmdXR1cmUN Cj4+PiBjb25zaXN0ZW5jeS4NCj4+IA0KPj4gU3VyZSAtIEknbSBhbGwgZm9yIGEgc21hdHRlcmlu ZyBvZiBpbmNvbnNpc3RlbmN5Oi0pDQo+PiANCj4+IEJ1dCBJIHRoaW5rIHRoZSBsYWNrIG9mIHNw ZWNzIGluIHNvbWUgb2YgdGhlc2UgY2FzZXMgY291bGQgaW1wYWN0DQo+PiBvbiBpbnRlcm9wLCBl LmcuIGluIHRoZSBvdHAgY2FzZSwgdGhleSBxdW90ZSB0d28gUkZDcyBhbmQgeWV0IG9ubHkNCj4+ IGhhdmUgb25lIHZhbHVlLiBUaGF0IHNlZW1zIGEgYml0IGJyb2tlbiB0byBtZSwgc28gdGhlIGRp c2N1c3MgaXNuJ3QNCj4+IHJlYWxseSBhYm91dCB0aGUgZm9ybWFsaXNtLg0KPj4gDQo+PiBTLg0K Pj4gDQo+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+PiANCj4+PiANCj4+IA0KPiANCg0K From nobody Wed Feb 1 16:31:28 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4085012960B; Wed, 1 Feb 2017 16:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuPI1Pa1VWzz; Wed, 1 Feb 2017 16:31:20 -0800 (PST) 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 64E67129577; Wed, 1 Feb 2017 16:31:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1EB13BE3E; Thu, 2 Feb 2017 00:31:18 +0000 (GMT) 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 CuCpDdOnM8MM; Thu, 2 Feb 2017 00:31:16 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5FF2BBE58; Thu, 2 Feb 2017 00:31:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485995475; bh=hRJCJjVZO5yg4B8UrrRR9172en2uGO01Q2lVYC5YCc8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=K+pY8g905VVspKUXOBhXZHgPKVXffsogZeXSFr+CUCAgfUzhI/RUkGJuzzAGXP7rs 2DmYMwDBWHbkZKIosIYcNh8p+r0THIBiv3tN7IKF7sE1roT4w+2v09NwB++z54Fhjl BeLi3srRwiZ6qrKmvPkw94Sz2B98R1enu+zzavRg= To: Mike Jones , Anthony Nadalin , joel jaeggli , The IESG References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> <268ffcf0-2f90-049e-1a3c-03b39d62c338@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 2 Feb 2017 00:31:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070007060109040107010304" Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:31:23 -0000 This is a cryptographically signed message in MIME format. --------------ms070007060109040107010304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/02/17 00:28, Mike Jones wrote: > The other case of known interop testing of "amr" values is for MODRNA > (OpenID Connect Mobile Profile) implementations. There's a reference > to its use of "amr" values in the spec. Yeah, iirc, that one seemed ok (assuming the reference tells me what code to write which I assume it does). I'm still not seeing why some do have sufficient references and others do not. Is there some difficulty with finding references or something? S >=20 > -----Original Message----- From: Anthony Nadalin Sent: Wednesday, > February 1, 2017 4:27 PM To: Stephen Farrell > ; Mike Jones > ; joel jaeggli ; The > IESG Cc: oauth-chairs@ietf.org; > draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org Subject: RE: > [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) >=20 > We have interoped between FIDO authenticators vendors and Windows > Hello >=20 > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, February 1, 2017 > 4:24 PM To: Mike Jones ; Anthony Nadalin > ; joel jaeggli ; The IESG > Cc: oauth-chairs@ietf.org; > draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org Subject: Re: > [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) >=20 >=20 >=20 > On 02/02/17 00:21, Mike Jones wrote: >> Thanks, Tony. I can add that reference. >>=20 >> Stephen, the sets of initial values were chosen from those used in=20 >> practice by Microsoft and Google in real deployments. >=20 > Genuine questions: do you aim to have interop between those=20 > deployments? What if I wanted to write code that'd interop with msft > or google? >=20 > S. >=20 >>=20 >> About "otp", there are existing use cases for indicating that an >> OTP was used. I'm not aware of any of these use cases where the=20 >> distinction between TOTP and HOTP is important. Thus, having >> "otp" now makes sense, where having "hotp" and "totp" now doesn't. >>=20 >> Stephen, this may seem like splitting hairs, but the registry=20 >> instructions for "Specification Document(s)" are about having a=20 >> reference for the document where the Authentication Method >> Reference Name (such as "otp") is defined. In all cases for the >> initial values, this is the RFC-to-be, so the registry instructions >> are satisfied. If someone were, for instance, to define the >> string "hotp", it would be incumbent on the person requesting its=20 >> registration to provide a URL to the document where the string >> "hotp" is defined. Also having a reference to RFC 4226 in that >> document would be a good thing, but that isn't what the registry >> instructions are about. >>=20 >> All that said, I can look at also finding appropriate references >> for the remaining values that don't currently have them. (Anyone >> got a good reference for password or PIN to suggest, for >> instance?) >>=20 >> -- Mike >>=20 >> -----Original Message----- From: Anthony Nadalin Sent: Wednesday,=20 >> February 1, 2017 4:10 PM To: Stephen Farrell=20 >> ; Mike Jones=20 >> ; joel jaeggli ; >> The IESG Cc: oauth-chairs@ietf.org;=20 >> draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org Subject: RE:=20 >> [OAUTH-WG] Stephen Farrell's Discuss on=20 >> draft-ietf-oauth-amr-values-05: (with DISCUSS) >>=20 >> NIST asked for the addition of IRIS (as they are seeing more use >> of IRIS over retina due to the accuracy of iris) as they have >> been doing significant testing on various iris devices and continue >> to do so, here is a report that NIST released=20 >> http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-re= port-evaluates-needle-haystack-search-capability.html >> >> >> >>=20 -----Original Message----- From: Stephen Farrell >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, February 1, >> 2017 2:26 PM To: Mike Jones ; joel >> jaeggli ; The IESG Cc:=20 >> oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org;=20 >> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss >> on draft-ietf-oauth-amr-values-05: (with DISCUSS) >>=20 >>=20 >> Hi Mike, >>=20 >> On 01/02/17 17:00, Mike Jones wrote: >>> Thanks for the discussion, Stephen. >>>=20 >>> To your point about "otp", the working group discussed this very >>> point. They explicitly decided not to introduce "hotp" and >>> "totp" identifiers because no one had a use case in which the >>> distinction mattered. >>=20 >> Then I'm not following why adding "otp" to the registry now is a >> good plan. >>=20 >> If there's a use-case now, then adding an entry with a good >> reference to the relevant spec seems right. >>=20 >> If there's no use-case now, then not adding it to the registry >> seems right. (Mentioning it as a possible future entry would be >> fine.) >>=20 >> I think the same logic would apply for all the values that this >> spec adds to the registry. Why is that wrong? >>=20 >>> Others can certainly introduce those identifiers and register >>> them if they do have such a use case, once the registry has been=20 >>> established. But the working group wanted to be conservative >>> about the identifiers introduced to prime the registry, and this >>> is such a case. >>>=20 >>> What identifiers to use and register will always be a balancing=20 >>> act. You want to be as specific as necessary to add practical >>> and usable value, but not so specific as to make things >>> unnecessarily brittle. >>=20 >> Eh... don't we want interop? Isn't that the primary goal here? >>=20 >>> While some might say there's a difference between serial number=20 >>> ranges of particular authentication devices, going there is=20 >>> clearly in the weeds. On the other hand, while there used to be >>> an "eye" identifier, Elaine Newton of NIST pointed out that there >>> are significant differences between retina and iris matching, so >>> "eye" was replaced with "retina" and "iris". Common sense >>> informed by actual data is the key here. >>=20 >> That's another good example. There's no reference for "iris." If >> that is used in some protocol, then what format(s) are expected to >> be supported? Where do I find that spec? If we can answer that, >> then great, let's add the details. If not, then I'd suggest we omit >> "iris" and leave it 'till later to add an entry for that. And >> again, including text with "iris" as an example is just fine, all >> I'm asking is that we only add the registry entry if we can meet >> the same bar that we're asking the DE to impose on later >> additions. >>=20 >> And the same for all the others... >>=20 >> Cheers, S. >>=20 >>=20 >>>=20 >>> The point of the registry requiring a specification reference is=20 >>> so people using the registry can tell where the identifier is=20 >>> defined. For all the initial values, that requirement is >>> satisfied, since the reference will be to the new RFC. I think >>> that aligns with the point that Joel was making. >>>=20 >>> Your thoughts? >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- From: OAuth=20 >>> [mailto:oauth-bounces@ietf.org] On Behalf Of Stephen Farrell >>> Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli=20 >>> ; The IESG Cc:=20 >>> oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org;=20 >>> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss=20 >>> on draft-ietf-oauth-amr-values-05: (with DISCUSS) >>>=20 >>>=20 >>>=20 >>> On 01/02/17 14:58, joel jaeggli wrote: >>>> On 1/31/17 8:26 AM, Stephen Farrell wrote: >>>>> Stephen Farrell has entered the following ballot position for >>>>> draft-ietf-oauth-amr-values-05: Discuss >>>>>=20 >>>>> 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.) >>>>>=20 >>>>>=20 >>>>> Please refer to=20 >>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>>>> more information about IESG DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found >>>>> here:=20 >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ >>>>> >>>>> >>>>> >>>>> >>>>>=20 --------------------------------------------------------------------- >>>>>=20 >>>>>=20 >>=20 >>>>>=20 > - >>>>> DISCUSS:=20 >>>>> -------------------------------------------------------------------= -- >>>>> >>>>> >> >>>>> > >>>>>=20 - >>>>>=20 >>>>> This specification seems to me to break it's own rules. You=20 >>>>> state that registrations should include a reference to a=20 >>>>> specification to improve interop. And yet, for the strings=20 >>>>> added here (e.g. otp) you don't do that (referring to section >>>>> 2 will not improve interop) and there are different ways in >>>>> which many of the methods in section 2 can be done. So I >>>>> think you need to add a bunch more references. >>>>=20 >>>> Not clear to me that the document creating the registry needs >>>> to adhere to the rules for further allocations in order to=20 >>>> prepoulate the registry. that is perhaps an appeal to future=20 >>>> consistency. >>>=20 >>> Sure - I'm all for a smattering of inconsistency:-) >>>=20 >>> But I think the lack of specs in some of these cases could >>> impact on interop, e.g. in the otp case, they quote two RFCs and >>> yet only have one value. That seems a bit broken to me, so the >>> discuss isn't really about the formalism. >>>=20 >>> S. >>>=20 >>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >=20 --------------ms070007060109040107010304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDIw MDMxMTRaMC8GCSqGSIb3DQEJBDEiBCDvaXEBKnnzfFWE9NLztzuSgBVMZVKGyLG3Wmf/aJ/q ZTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAcnSbUpGbHrmCb7seauDuyrFd7TU2fhhINGSFZsuMbOsfbsBKWDtic 4fJ68IsKpKHGfrmfn+qn6JrW+5/bIRLZSccu0vlvYhCeVPIyM3GNTftVG2aK7lll9ewNbfDG ll148Sv9GZzroL123DJaSNc5SwAfXalxkf6Xnr/WpamvN2+4AdKNB0aaPbCvxKP0Ac3W/zXl mdYSFQ90s352TOTVPrFodBo7BPK3TzefqFYSletqXjauRIkamd/1Bxg1vbKJttLzPpFxBWUw sUDo6o1SBuTbrcIKECctyjciQ4h8fykTHw1p9H//qIKE1CNJ22CkR0yAoj90C/BlJzJsTxx1 AAAAAAAA --------------ms070007060109040107010304-- From nobody Wed Feb 1 16:35:45 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA380129577; Wed, 1 Feb 2017 16:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2_OtpSWNyc2; Wed, 1 Feb 2017 16:35:37 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0108.outbound.protection.outlook.com [104.47.36.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08731294F0; Wed, 1 Feb 2017 16:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KVPMZAU/jJoLmTJ+5qR93vkRAutFNl0J4MBT/5IB1f4=; b=OTaHem5xOYqzU0idXk+7ZBSXVcyDu4gIAOAQ5B9vHTnZdaNUNdgqNAM1tDjPIw6r3rXS3AEKzUIGr8eIwbLw2htbhgyxJTi+9+pY/r5ofgGk3D2szdp3EG25lTGffH5lEGOAHlPc81GEmQkSgBCH4B3287kzpspNXoXrkRfzvYI= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by CY1PR0301MB2027.namprd03.prod.outlook.com (10.164.2.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 00:35:34 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0874.021; Thu, 2 Feb 2017 00:35:33 +0000 From: Mike Jones To: Stephen Farrell , Anthony Nadalin , joel jaeggli , The IESG Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) Thread-Index: AQHSe97H5hXZpqeBE0CT6lHMY4yQFKFUP6sAgAABIQCAAB5D0IAAXXiAgAAdOACAAABqIIAAA2uAgAAA3wCAAAAzAIAAAO4AgAAAVZA= Date: Thu, 2 Feb 2017 00:35:33 +0000 Message-ID: References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> <268ffcf0-2f90-049e-1a3c-03b39d62c338@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:c::388] x-ms-office365-filtering-correlation-id: b6d264ec-960a-41fe-ca75-08d44b036623 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB2027; x-microsoft-exchange-diagnostics: 1; CY1PR0301MB2027; 7:G4XjEiRby3EmiiZeij17gkDxFlQ2OzVQwagJS/5ydtQvFKqxbJw6cyU9exroXdbpu+eSTSncmrytUq22mWOBdVpbtP+/e8p8KoUZ4VHTFlTBdwPjWgIyd+77A5fI/Z86OkjNz0NYIQ9j62IeAXU147vS92fa0JozFIwvsI2U3hABmDz+k+b4CxMgolG+R3fAL+o906ppN+jPJa58IUovm8IbphLffhoURYOTiMeMO3+HPtx8m4L/01Kk2nnQlltLYTTglkAouR0fD3Q+Lw6R6Fo9lfAlilUSBh8gLOJ7zcCFhOOPAO/j0/bwrxSzgRO8E+etfAJhgUwwS3sdqaerQFRs9IN7f6ONUlaLXfx8I/fE5uXIvaTSgruG9ggu++l/tRgKOZ5F6RufJRl053X2myZuLCIq49KjT4vZVBbW3OnVX3ZDeLZC/0Om8U8opGd3oSc4k3TmdOgrznAGphgoZjdeMWnYJJImaV62sGQStZvJOYM3zRPCRYcecMSCkBT0SrsbJofYaS0IbE3GsvFchosafDfjmtCFZ6go/M/XRp3PxBB5ggu+cNp9TNlz7pve x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(120809045254105)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(20161123558025)(6072148); SRVR:CY1PR0301MB2027; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB2027; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39450400003)(39410400002)(39840400002)(199003)(13464003)(24454002)(40224003)(377454003)(189002)(51914003)(1511001)(86612001)(6436002)(106356001)(305945005)(77096006)(10090500001)(229853002)(122556002)(105586002)(38730400001)(6506006)(53936002)(106116001)(551544002)(99286003)(7736002)(54906002)(966004)(25786008)(55016002)(189998001)(93886004)(50986999)(54356999)(101416001)(76176999)(230783001)(9686003)(6306002)(8676002)(86362001)(97736004)(81156014)(92566002)(5660300001)(81166006)(5001770100001)(2950100002)(2561002)(33656002)(2421001)(7696004)(4326007)(3900700001)(3280700002)(2906002)(8936002)(68736007)(3660700001)(74316002)(2900100001)(6116002)(102836003)(8990500004)(5005710100001)(10290500002)(522254002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB2027; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 00:35:33.3906 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB2027 Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:35:40 -0000 WW91IGNhbiBjYWxsIG1lIGxhenkgaWYgeW91IHdhbnQuICBTb21lIG9mIHRoZW0gYXJlIHNvIHdl bGwga25vd24sIHN1Y2ggYXMgInBhc3N3b3JkIiBvciAiUElOIiBpdCBkaWRuJ3Qgc2VlbSB3b3J0 aHdoaWxlIHRvIHRyeSB0byB0cmFjayBkb3duIGEgcmVmZXJlbmNlLiAgQnV0IEknbSB3aWxsaW5n IHRvIHdvcmsgd2l0aCBvdGhlcnMgdG8gZmluZCBkZWNlbnQgcmVmZXJlbmNlcyBmb3IgdGhlIHJl c3Qgb2YgdGhlbSwgaWYgeW91IGJlbGlldmUgdGhhdCB3b3VsZCBpbXByb3ZlIHRoZSBxdWFsaXR5 IG9mIHRoZSBzcGVjaWZpY2F0aW9uLg0KDQoJCQkJQmVzdCB3aXNoZXMsDQoJCQkJLS0gTWlrZQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWls dG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDEsIDIwMTcgNDozMSBQTQ0KVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0 LmNvbT47IEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPjsgam9lbCBqYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogb2F1 dGgtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7 IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTdGVwaGVuIEZhcnJlbGwn cyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlcy0wNTogKHdpdGggRElTQ1VT UykNCg0KDQoNCk9uIDAyLzAyLzE3IDAwOjI4LCBNaWtlIEpvbmVzIHdyb3RlOg0KPiBUaGUgb3Ro ZXIgY2FzZSBvZiBrbm93biBpbnRlcm9wIHRlc3Rpbmcgb2YgImFtciIgdmFsdWVzIGlzIGZvciBN T0RSTkENCj4gKE9wZW5JRCBDb25uZWN0IE1vYmlsZSBQcm9maWxlKSBpbXBsZW1lbnRhdGlvbnMu ICBUaGVyZSdzIGEgcmVmZXJlbmNlDQo+IHRvIGl0cyB1c2Ugb2YgImFtciIgdmFsdWVzIGluIHRo ZSBzcGVjLg0KDQpZZWFoLCBpaXJjLCB0aGF0IG9uZSBzZWVtZWQgb2sgKGFzc3VtaW5nIHRoZSBy ZWZlcmVuY2UgdGVsbHMNCm1lIHdoYXQgY29kZSB0byB3cml0ZSB3aGljaCBJIGFzc3VtZSBpdCBk b2VzKS4NCg0KSSdtIHN0aWxsIG5vdCBzZWVpbmcgd2h5IHNvbWUgZG8gaGF2ZSBzdWZmaWNpZW50 IHJlZmVyZW5jZXMNCmFuZCBvdGhlcnMgZG8gbm90Lg0KDQpJcyB0aGVyZSBzb21lIGRpZmZpY3Vs dHkgd2l0aCBmaW5kaW5nIHJlZmVyZW5jZXMgb3Igc29tZXRoaW5nPw0KDQpTDQoNCj4gDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IEFudGhvbnkgTmFkYWxpbiBTZW50OiBXZWRu ZXNkYXksDQo+IEZlYnJ1YXJ5IDEsIDIwMTcgNDoyNyBQTSBUbzogU3RlcGhlbiBGYXJyZWxsDQo+ IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPjsgTWlrZSBKb25lcw0KPiA8TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPjsgam9lbCBqYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPjsgVGhlDQo+ IElFU0cgPGllc2dAaWV0Zi5vcmc+IENjOiBvYXV0aC1jaGFpcnNAaWV0Zi5vcmc7DQo+IGRyYWZ0 LWlldGYtb2F1dGgtYW1yLXZhbHVlc0BpZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmcgU3ViamVjdDog UkU6DQo+IFtPQVVUSC1XR10gU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbg0KPiBkcmFmdC1p ZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6ICh3aXRoIERJU0NVU1MpDQo+IA0KPiBXZSBoYXZlIGlu dGVyb3BlZCBiZXR3ZWVuIEZJRE8gYXV0aGVudGljYXRvcnMgdmVuZG9ycyBhbmQgV2luZG93cw0K PiBIZWxsbw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogU3RlcGhlbiBG YXJyZWxsDQo+IFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gU2VudDogV2VkbmVz ZGF5LCBGZWJydWFyeSAxLCAyMDE3DQo+IDQ6MjQgUE0gVG86IE1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT47IEFudGhvbnkgTmFkYWxpbg0KPiA8dG9ueW5hZEBtaWNyb3Nv ZnQuY29tPjsgam9lbCBqYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPjsgVGhlIElFU0cNCj4gPGll c2dAaWV0Zi5vcmc+IENjOiBvYXV0aC1jaGFpcnNAaWV0Zi5vcmc7DQo+IGRyYWZ0LWlldGYtb2F1 dGgtYW1yLXZhbHVlc0BpZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmcgU3ViamVjdDogUmU6DQo+IFtP QVVUSC1XR10gU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbg0KPiBkcmFmdC1pZXRmLW9hdXRo LWFtci12YWx1ZXMtMDU6ICh3aXRoIERJU0NVU1MpDQo+IA0KPiANCj4gDQo+IE9uIDAyLzAyLzE3 IDAwOjIxLCBNaWtlIEpvbmVzIHdyb3RlOg0KPj4gVGhhbmtzLCBUb255LiAgSSBjYW4gYWRkIHRo YXQgcmVmZXJlbmNlLg0KPj4gDQo+PiBTdGVwaGVuLCB0aGUgc2V0cyBvZiBpbml0aWFsIHZhbHVl cyB3ZXJlIGNob3NlbiBmcm9tIHRob3NlIHVzZWQgaW4gDQo+PiBwcmFjdGljZSBieSBNaWNyb3Nv ZnQgYW5kIEdvb2dsZSBpbiByZWFsIGRlcGxveW1lbnRzLg0KPiANCj4gR2VudWluZSBxdWVzdGlv bnM6IGRvIHlvdSBhaW0gdG8gaGF2ZSBpbnRlcm9wIGJldHdlZW4gdGhvc2UgDQo+IGRlcGxveW1l bnRzPyBXaGF0IGlmIEkgd2FudGVkIHRvIHdyaXRlIGNvZGUgdGhhdCdkIGludGVyb3Agd2l0aCBt c2Z0DQo+IG9yIGdvb2dsZT8NCj4gDQo+IFMuDQo+IA0KPj4gDQo+PiBBYm91dCAib3RwIiwgdGhl cmUgYXJlIGV4aXN0aW5nIHVzZSBjYXNlcyBmb3IgaW5kaWNhdGluZyB0aGF0IGFuDQo+PiBPVFAg d2FzIHVzZWQuICBJJ20gbm90IGF3YXJlIG9mIGFueSBvZiB0aGVzZSB1c2UgY2FzZXMgd2hlcmUg dGhlIA0KPj4gZGlzdGluY3Rpb24gYmV0d2VlbiBUT1RQIGFuZCBIT1RQIGlzIGltcG9ydGFudC4g IFRodXMsIGhhdmluZw0KPj4gIm90cCIgbm93IG1ha2VzIHNlbnNlLCB3aGVyZSBoYXZpbmcgImhv dHAiIGFuZCAidG90cCIgbm93IGRvZXNuJ3QuDQo+PiANCj4+IFN0ZXBoZW4sIHRoaXMgbWF5IHNl ZW0gbGlrZSBzcGxpdHRpbmcgaGFpcnMsIGJ1dCB0aGUgcmVnaXN0cnkgDQo+PiBpbnN0cnVjdGlv bnMgZm9yICJTcGVjaWZpY2F0aW9uIERvY3VtZW50KHMpIiBhcmUgYWJvdXQgaGF2aW5nIGEgDQo+ PiByZWZlcmVuY2UgZm9yIHRoZSBkb2N1bWVudCB3aGVyZSB0aGUgQXV0aGVudGljYXRpb24gTWV0 aG9kDQo+PiBSZWZlcmVuY2UgTmFtZSAoc3VjaCBhcyAib3RwIikgaXMgZGVmaW5lZC4gIEluIGFs bCBjYXNlcyBmb3IgdGhlDQo+PiBpbml0aWFsIHZhbHVlcywgdGhpcyBpcyB0aGUgUkZDLXRvLWJl LCBzbyB0aGUgcmVnaXN0cnkgaW5zdHJ1Y3Rpb25zDQo+PiBhcmUgc2F0aXNmaWVkLiAgSWYgc29t ZW9uZSB3ZXJlLCBmb3IgaW5zdGFuY2UsIHRvIGRlZmluZSB0aGUNCj4+IHN0cmluZyAiaG90cCIs IGl0IHdvdWxkIGJlIGluY3VtYmVudCBvbiB0aGUgcGVyc29uIHJlcXVlc3RpbmcgaXRzIA0KPj4g cmVnaXN0cmF0aW9uIHRvIHByb3ZpZGUgYSBVUkwgdG8gdGhlIGRvY3VtZW50IHdoZXJlIHRoZSBz dHJpbmcNCj4+ICJob3RwIiBpcyBkZWZpbmVkLiAgQWxzbyBoYXZpbmcgYSByZWZlcmVuY2UgdG8g UkZDIDQyMjYgaW4gdGhhdA0KPj4gZG9jdW1lbnQgd291bGQgYmUgYSBnb29kIHRoaW5nLCBidXQg dGhhdCBpc24ndCB3aGF0IHRoZSByZWdpc3RyeQ0KPj4gaW5zdHJ1Y3Rpb25zIGFyZSBhYm91dC4N Cj4+IA0KPj4gQWxsIHRoYXQgc2FpZCwgSSBjYW4gbG9vayBhdCBhbHNvIGZpbmRpbmcgYXBwcm9w cmlhdGUgcmVmZXJlbmNlcw0KPj4gZm9yIHRoZSByZW1haW5pbmcgdmFsdWVzIHRoYXQgZG9uJ3Qg Y3VycmVudGx5IGhhdmUgdGhlbS4gIChBbnlvbmUNCj4+IGdvdCBhIGdvb2QgcmVmZXJlbmNlIGZv ciBwYXNzd29yZCBvciBQSU4gdG8gc3VnZ2VzdCwgZm9yDQo+PiBpbnN0YW5jZT8pDQo+PiANCj4+ IC0tIE1pa2UNCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogQW50aG9u eSBOYWRhbGluIFNlbnQ6IFdlZG5lc2RheSwgDQo+PiBGZWJydWFyeSAxLCAyMDE3IDQ6MTAgUE0g VG86IFN0ZXBoZW4gRmFycmVsbCANCj4+IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPjsgTWlr ZSBKb25lcyANCj4+IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBqb2VsIGphZWdnbGkg PGpvZWxqYUBib2d1cy5jb20+Ow0KPj4gVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+IENjOiBvYXV0 aC1jaGFpcnNAaWV0Zi5vcmc7IA0KPj4gZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzQGlldGYu b3JnOyBvYXV0aEBpZXRmLm9yZyBTdWJqZWN0OiBSRTogDQo+PiBbT0FVVEgtV0ddIFN0ZXBoZW4g RmFycmVsbCdzIERpc2N1c3Mgb24gDQo+PiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6 ICh3aXRoIERJU0NVU1MpDQo+PiANCj4+IE5JU1QgYXNrZWQgZm9yIHRoZSBhZGRpdGlvbiBvZiBJ UklTIChhcyB0aGV5IGFyZSBzZWVpbmcgbW9yZSB1c2UNCj4+IG9mIElSSVMgb3ZlciByZXRpbmEg ZHVlIHRvIHRoZSBhY2N1cmFjeSBvZiBpcmlzKSAgYXMgdGhleSBoYXZlDQo+PiBiZWVuIGRvaW5n IHNpZ25pZmljYW50IHRlc3Rpbmcgb24gdmFyaW91cyBpcmlzIGRldmljZXMgYW5kIGNvbnRpbnVl DQo+PiB0byBkbyBzbywgaGVyZSBpcyBhIHJlcG9ydCB0aGF0IE5JU1QgcmVsZWFzZWQgDQo+PiBo dHRwOi8vMjAxMC0yMDE0LmNvbW1lcmNlLmdvdi9ibG9nLzIwMTIvMDQvMjMvbmlzdC1pcmlzLXJl Y29nbml0aW9uLXJlcG9ydC1ldmFsdWF0ZXMtbmVlZGxlLWhheXN0YWNrLXNlYXJjaC1jYXBhYmls aXR5Lmh0bWwNCj4+DQo+Pg0KPj4NCj4+IA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJv bTogU3RlcGhlbiBGYXJyZWxsDQo+PiBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVd IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMSwNCj4+IDIwMTcgMjoyNiBQTSBUbzogTWlrZSBK b25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgam9lbA0KPj4gamFlZ2dsaSA8am9l bGphQGJvZ3VzLmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPiBDYzogDQo+PiBvYXV0aC1j aGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlc0BpZXRmLm9yZzsgDQo+ PiBvYXV0aEBpZXRmLm9yZyBTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTdGVwaGVuIEZhcnJlbGwn cyBEaXNjdXNzDQo+PiBvbiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6ICh3aXRoIERJ U0NVU1MpDQo+PiANCj4+IA0KPj4gSGkgTWlrZSwNCj4+IA0KPj4gT24gMDEvMDIvMTcgMTc6MDAs IE1pa2UgSm9uZXMgd3JvdGU6DQo+Pj4gVGhhbmtzIGZvciB0aGUgZGlzY3Vzc2lvbiwgU3RlcGhl bi4NCj4+PiANCj4+PiBUbyB5b3VyIHBvaW50IGFib3V0ICJvdHAiLCB0aGUgd29ya2luZyBncm91 cCBkaXNjdXNzZWQgdGhpcyB2ZXJ5DQo+Pj4gIHBvaW50LiAgVGhleSBleHBsaWNpdGx5IGRlY2lk ZWQgbm90IHRvIGludHJvZHVjZSAiaG90cCIgYW5kDQo+Pj4gInRvdHAiIGlkZW50aWZpZXJzIGJl Y2F1c2Ugbm8gb25lIGhhZCBhIHVzZSBjYXNlIGluIHdoaWNoIHRoZQ0KPj4+IGRpc3RpbmN0aW9u IG1hdHRlcmVkLg0KPj4gDQo+PiBUaGVuIEknbSBub3QgZm9sbG93aW5nIHdoeSBhZGRpbmcgIm90 cCIgdG8gdGhlIHJlZ2lzdHJ5IG5vdyBpcyBhDQo+PiBnb29kIHBsYW4uDQo+PiANCj4+IElmIHRo ZXJlJ3MgYSB1c2UtY2FzZSBub3csIHRoZW4gYWRkaW5nIGFuIGVudHJ5IHdpdGggYSBnb29kDQo+ PiByZWZlcmVuY2UgdG8gdGhlIHJlbGV2YW50IHNwZWMgc2VlbXMgcmlnaHQuDQo+PiANCj4+IElm IHRoZXJlJ3Mgbm8gdXNlLWNhc2Ugbm93LCB0aGVuIG5vdCBhZGRpbmcgaXQgdG8gdGhlIHJlZ2lz dHJ5DQo+PiBzZWVtcyByaWdodC4gKE1lbnRpb25pbmcgaXQgYXMgYSBwb3NzaWJsZSBmdXR1cmUg ZW50cnkgd291bGQgYmUNCj4+IGZpbmUuKQ0KPj4gDQo+PiBJIHRoaW5rIHRoZSBzYW1lIGxvZ2lj IHdvdWxkIGFwcGx5IGZvciBhbGwgdGhlIHZhbHVlcyB0aGF0IHRoaXMNCj4+IHNwZWMgYWRkcyB0 byB0aGUgcmVnaXN0cnkuIFdoeSBpcyB0aGF0IHdyb25nPw0KPj4gDQo+Pj4gT3RoZXJzIGNhbiBj ZXJ0YWlubHkgaW50cm9kdWNlIHRob3NlIGlkZW50aWZpZXJzIGFuZCByZWdpc3Rlcg0KPj4+IHRo ZW0gaWYgdGhleSBkbyBoYXZlIHN1Y2ggYSB1c2UgY2FzZSwgb25jZSB0aGUgcmVnaXN0cnkgaGFz IGJlZW4gDQo+Pj4gZXN0YWJsaXNoZWQuICBCdXQgdGhlIHdvcmtpbmcgZ3JvdXAgd2FudGVkIHRv IGJlIGNvbnNlcnZhdGl2ZQ0KPj4+IGFib3V0IHRoZSBpZGVudGlmaWVycyBpbnRyb2R1Y2VkIHRv IHByaW1lIHRoZSByZWdpc3RyeSwgYW5kIHRoaXMNCj4+PiBpcyBzdWNoIGEgY2FzZS4NCj4+PiAN Cj4+PiBXaGF0IGlkZW50aWZpZXJzIHRvIHVzZSBhbmQgcmVnaXN0ZXIgd2lsbCBhbHdheXMgYmUg YSBiYWxhbmNpbmcgDQo+Pj4gYWN0LiBZb3Ugd2FudCB0byBiZSBhcyBzcGVjaWZpYyBhcyBuZWNl c3NhcnkgdG8gYWRkIHByYWN0aWNhbA0KPj4+IGFuZCB1c2FibGUgdmFsdWUsIGJ1dCBub3Qgc28g c3BlY2lmaWMgYXMgdG8gbWFrZSB0aGluZ3MNCj4+PiB1bm5lY2Vzc2FyaWx5IGJyaXR0bGUuDQo+ PiANCj4+IEVoLi4uIGRvbid0IHdlIHdhbnQgaW50ZXJvcD8gSXNuJ3QgdGhhdCB0aGUgcHJpbWFy eSBnb2FsIGhlcmU/DQo+PiANCj4+PiBXaGlsZSBzb21lIG1pZ2h0IHNheSB0aGVyZSdzIGEgZGlm ZmVyZW5jZSBiZXR3ZWVuIHNlcmlhbCBudW1iZXIgDQo+Pj4gcmFuZ2VzIG9mIHBhcnRpY3VsYXIg YXV0aGVudGljYXRpb24gZGV2aWNlcywgZ29pbmcgdGhlcmUgaXMgDQo+Pj4gY2xlYXJseSBpbiB0 aGUgd2VlZHMuICBPbiB0aGUgb3RoZXIgaGFuZCwgd2hpbGUgdGhlcmUgdXNlZCB0byBiZQ0KPj4+ IGFuICJleWUiIGlkZW50aWZpZXIsIEVsYWluZSBOZXd0b24gb2YgTklTVCBwb2ludGVkIG91dCB0 aGF0IHRoZXJlDQo+Pj4gYXJlIHNpZ25pZmljYW50IGRpZmZlcmVuY2VzIGJldHdlZW4gcmV0aW5h IGFuZCBpcmlzIG1hdGNoaW5nLCBzbw0KPj4+ICJleWUiIHdhcyByZXBsYWNlZCB3aXRoICJyZXRp bmEiIGFuZCAiaXJpcyIuICBDb21tb24gc2Vuc2UNCj4+PiBpbmZvcm1lZCBieSBhY3R1YWwgZGF0 YSBpcyB0aGUga2V5IGhlcmUuDQo+PiANCj4+IFRoYXQncyBhbm90aGVyIGdvb2QgZXhhbXBsZS4g VGhlcmUncyBubyByZWZlcmVuY2UgZm9yICJpcmlzLiIgSWYNCj4+IHRoYXQgaXMgdXNlZCBpbiBz b21lIHByb3RvY29sLCB0aGVuIHdoYXQgZm9ybWF0KHMpIGFyZSBleHBlY3RlZCB0bw0KPj4gYmUg c3VwcG9ydGVkPyBXaGVyZSBkbyBJIGZpbmQgdGhhdCBzcGVjPyBJZiB3ZSBjYW4gYW5zd2VyIHRo YXQsDQo+PiB0aGVuIGdyZWF0LCBsZXQncyBhZGQgdGhlIGRldGFpbHMuIElmIG5vdCwgdGhlbiBJ J2Qgc3VnZ2VzdCB3ZSBvbWl0DQo+PiAiaXJpcyIgYW5kIGxlYXZlIGl0ICd0aWxsIGxhdGVyIHRv IGFkZCBhbiBlbnRyeSBmb3IgdGhhdC4gQW5kDQo+PiBhZ2FpbiwgaW5jbHVkaW5nIHRleHQgd2l0 aCAiaXJpcyIgYXMgYW4gZXhhbXBsZSBpcyBqdXN0IGZpbmUsIGFsbA0KPj4gSSdtIGFza2luZyBp cyB0aGF0IHdlIG9ubHkgYWRkIHRoZSByZWdpc3RyeSBlbnRyeSBpZiB3ZSBjYW4gbWVldA0KPj4g dGhlIHNhbWUgYmFyIHRoYXQgd2UncmUgYXNraW5nIHRoZSBERSB0byBpbXBvc2Ugb24gbGF0ZXIN Cj4+IGFkZGl0aW9ucy4NCj4+IA0KPj4gQW5kIHRoZSBzYW1lIGZvciBhbGwgdGhlIG90aGVycy4u Lg0KPj4gDQo+PiBDaGVlcnMsIFMuDQo+PiANCj4+IA0KPj4+IA0KPj4+IFRoZSBwb2ludCBvZiB0 aGUgcmVnaXN0cnkgcmVxdWlyaW5nIGEgc3BlY2lmaWNhdGlvbiByZWZlcmVuY2UgaXMgDQo+Pj4g c28gcGVvcGxlIHVzaW5nIHRoZSByZWdpc3RyeSBjYW4gdGVsbCB3aGVyZSB0aGUgaWRlbnRpZmll ciBpcyANCj4+PiBkZWZpbmVkLiBGb3IgYWxsIHRoZSBpbml0aWFsIHZhbHVlcywgdGhhdCByZXF1 aXJlbWVudCBpcw0KPj4+IHNhdGlzZmllZCwgc2luY2UgdGhlIHJlZmVyZW5jZSB3aWxsIGJlIHRv IHRoZSBuZXcgUkZDLiAgSSB0aGluaw0KPj4+IHRoYXQgYWxpZ25zIHdpdGggdGhlIHBvaW50IHRo YXQgSm9lbCB3YXMgbWFraW5nLg0KPj4+IA0KPj4+IFlvdXIgdGhvdWdodHM/DQo+Pj4gDQo+Pj4g LS0gTWlrZQ0KPj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IE9BdXRo IA0KPj4+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXBo ZW4gRmFycmVsbA0KPj4+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMSwgMjAxNyA3OjAzIEFN IFRvOiBqb2VsIGphZWdnbGkgDQo+Pj4gPGpvZWxqYUBib2d1cy5jb20+OyBUaGUgSUVTRyA8aWVz Z0BpZXRmLm9yZz4gQ2M6IA0KPj4+IG9hdXRoLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1v YXV0aC1hbXItdmFsdWVzQGlldGYub3JnOyANCj4+PiBvYXV0aEBpZXRmLm9yZyBTdWJqZWN0OiBS ZTogW09BVVRILVdHXSBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIA0KPj4+IG9uIGRyYWZ0LWll dGYtb2F1dGgtYW1yLXZhbHVlcy0wNTogKHdpdGggRElTQ1VTUykNCj4+PiANCj4+PiANCj4+PiAN Cj4+PiBPbiAwMS8wMi8xNyAxNDo1OCwgam9lbCBqYWVnZ2xpIHdyb3RlOg0KPj4+PiBPbiAxLzMx LzE3IDg6MjYgQU0sIFN0ZXBoZW4gRmFycmVsbCB3cm90ZToNCj4+Pj4+IFN0ZXBoZW4gRmFycmVs bCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4+Pj4+ICBk cmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6IERpc2N1c3MNCj4+Pj4+IA0KPj4+Pj4gV2hl biByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQNCj4+ Pj4+IHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBD QyBsaW5lcy4NCj4+Pj4+IChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFn cmFwaCwgaG93ZXZlci4pDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gUGxlYXNlIHJlZmVyIHRvIA0K Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJp YS5odG1sIGZvcg0KPj4+Pj4gIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFu ZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBUaGUgZG9jdW1lbnQs IGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kDQo+Pj4+PiAg aGVyZTogDQo+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LW9hdXRoLWFtci12YWx1ZXMvDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+Pj4+IA0KPj4+Pj4gDQo+PiANCj4+Pj4+IA0KPiAtDQo+Pj4+PiBESVND VVNTOiANCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4NCj4+Pj4+DQo+Pg0KPj4+Pj4NCj4NCj4+ Pj4+IA0KLQ0KPj4+Pj4gDQo+Pj4+PiBUaGlzIHNwZWNpZmljYXRpb24gc2VlbXMgdG8gbWUgdG8g YnJlYWsgaXQncyBvd24gcnVsZXMuIFlvdSANCj4+Pj4+IHN0YXRlIHRoYXQgcmVnaXN0cmF0aW9u cyBzaG91bGQgaW5jbHVkZSBhIHJlZmVyZW5jZSB0byBhIA0KPj4+Pj4gc3BlY2lmaWNhdGlvbiB0 byBpbXByb3ZlIGludGVyb3AuIEFuZCB5ZXQsIGZvciB0aGUgc3RyaW5ncyANCj4+Pj4+IGFkZGVk IGhlcmUgKGUuZy4gb3RwKSB5b3UgZG9uJ3QgZG8gdGhhdCAocmVmZXJyaW5nIHRvIHNlY3Rpb24N Cj4+Pj4+IDIgd2lsbCBub3QgaW1wcm92ZSBpbnRlcm9wKSBhbmQgdGhlcmUgYXJlIGRpZmZlcmVu dCB3YXlzIGluDQo+Pj4+PiB3aGljaCBtYW55IG9mIHRoZSBtZXRob2RzIGluIHNlY3Rpb24gMiBj YW4gYmUgZG9uZS4gU28gSQ0KPj4+Pj4gdGhpbmsgeW91IG5lZWQgdG8gYWRkIGEgYnVuY2ggbW9y ZSByZWZlcmVuY2VzLg0KPj4+PiANCj4+Pj4gTm90IGNsZWFyIHRvIG1lIHRoYXQgdGhlIGRvY3Vt ZW50IGNyZWF0aW5nIHRoZSByZWdpc3RyeSBuZWVkcw0KPj4+PiB0byBhZGhlcmUgdG8gdGhlIHJ1 bGVzIGZvciBmdXJ0aGVyIGFsbG9jYXRpb25zIGluIG9yZGVyIHRvIA0KPj4+PiBwcmVwb3VsYXRl IHRoZSByZWdpc3RyeS4gdGhhdCBpcyBwZXJoYXBzIGFuIGFwcGVhbCB0byBmdXR1cmUgDQo+Pj4+ IGNvbnNpc3RlbmN5Lg0KPj4+IA0KPj4+IFN1cmUgLSBJJ20gYWxsIGZvciBhIHNtYXR0ZXJpbmcg b2YgaW5jb25zaXN0ZW5jeTotKQ0KPj4+IA0KPj4+IEJ1dCBJIHRoaW5rIHRoZSBsYWNrIG9mIHNw ZWNzIGluIHNvbWUgb2YgdGhlc2UgY2FzZXMgY291bGQNCj4+PiBpbXBhY3Qgb24gaW50ZXJvcCwg ZS5nLiBpbiB0aGUgb3RwIGNhc2UsIHRoZXkgcXVvdGUgdHdvIFJGQ3MgYW5kDQo+Pj4geWV0IG9u bHkgaGF2ZSBvbmUgdmFsdWUuIFRoYXQgc2VlbXMgYSBiaXQgYnJva2VuIHRvIG1lLCBzbyB0aGUN Cj4+PiBkaXNjdXNzIGlzbid0IHJlYWxseSBhYm91dCB0aGUgZm9ybWFsaXNtLg0KPj4+IA0KPj4+ IFMuDQo+Pj4gDQo+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+ PiANCj4+IA0KPiANCg0K From nobody Wed Feb 1 16:45:11 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C11129606; Wed, 1 Feb 2017 16:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEiIrM4gTPuO; Wed, 1 Feb 2017 16:45:08 -0800 (PST) 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 A31F4129616; Wed, 1 Feb 2017 16:45:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 69192BE58; Thu, 2 Feb 2017 00:45:05 +0000 (GMT) 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 1k1cwJ1loLoJ; Thu, 2 Feb 2017 00:45:03 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 57CC9BE3E; Thu, 2 Feb 2017 00:45:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485996303; bh=2lA+XKpSzzbSV81UODhopzDIPNJm6m5LatO+ynzbDz4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=0ysOBniA5RhmrpPNvLOhfjYtaty/aF+z6MXMxTgVef8FT14rk7vdPgQM5ZvIIBEOF 5l2V8HE/1OBBwWG6c1cygmf/eFmsv9BsUYC1AXgjQWEZebtTnmky2eRBqd1IFHnBhP yR071SQiFjGPJfiuD6bE2gvPKuFy3gswwFbZ+tUA= To: Mike Jones , Anthony Nadalin , joel jaeggli , The IESG References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> <268ffcf0-2f90-049e-1a3c-03b39d62c338@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2972e6a5-2bdb-3047-2086-271730dfc3ef@cs.tcd.ie> Date: Thu, 2 Feb 2017 00:45:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060104020408060905030808" Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:45:10 -0000 This is a cryptographically signed message in MIME format. --------------ms060104020408060905030808 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/02/17 00:35, Mike Jones wrote: > You can call me lazy if you want.=20 I don't think you're lazy:-) Were I to guess I'd guess that interop for these wasn't a priority and that we're defining them a bit early and a little too generically. > Some of them are so well known, > such as "password" or "PIN" it didn't seem worthwhile to try to track > down a reference.=20 Sure, those are fine. The only issues would be if there's a string2key function somewhere but I don't expect there is in this context. > But I'm willing to work with others to find decent > references for the rest of them, if you believe that would improve > the quality of the specification. I do think it would, esp for cases where there are known different options (e.g. otp) or likely ill-defined or proprietary formats. My guess is that some biometrics fit that latter but I could be wrong. If they do, then one runs into the problem of having to depend on magic numbers in the encodings or similar to distinguish which is really error prone and likely to lead to what our learned transport chums are calling ossification;-) Cheers, S. >=20 > Best wishes, -- Mike >=20 > -----Original Message----- From: Stephen Farrell > [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, February 1, 2017 > 4:31 PM To: Mike Jones ; Anthony Nadalin > ; joel jaeggli ; The IESG > Cc: oauth-chairs@ietf.org; > draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org Subject: Re: > [OAUTH-WG] Stephen Farrell's Discuss on > draft-ietf-oauth-amr-values-05: (with DISCUSS) >=20 >=20 >=20 > On 02/02/17 00:28, Mike Jones wrote: >> The other case of known interop testing of "amr" values is for >> MODRNA (OpenID Connect Mobile Profile) implementations. There's a >> reference to its use of "amr" values in the spec. >=20 > Yeah, iirc, that one seemed ok (assuming the reference tells me what > code to write which I assume it does). >=20 > I'm still not seeing why some do have sufficient references and > others do not. >=20 > Is there some difficulty with finding references or something? >=20 > S >=20 >>=20 >> -----Original Message----- From: Anthony Nadalin Sent: Wednesday,=20 >> February 1, 2017 4:27 PM To: Stephen Farrell=20 >> ; Mike Jones=20 >> ; joel jaeggli ; >> The IESG Cc: oauth-chairs@ietf.org;=20 >> draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org Subject: RE:=20 >> [OAUTH-WG] Stephen Farrell's Discuss on=20 >> draft-ietf-oauth-amr-values-05: (with DISCUSS) >>=20 >> We have interoped between FIDO authenticators vendors and Windows=20 >> Hello >>=20 >> -----Original Message----- From: Stephen Farrell=20 >> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, February 1, >> 2017 4:24 PM To: Mike Jones ; Anthony >> Nadalin ; joel jaeggli ; >> The IESG Cc: oauth-chairs@ietf.org;=20 >> draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org Subject: Re:=20 >> [OAUTH-WG] Stephen Farrell's Discuss on=20 >> draft-ietf-oauth-amr-values-05: (with DISCUSS) >>=20 >>=20 >>=20 >> On 02/02/17 00:21, Mike Jones wrote: >>> Thanks, Tony. I can add that reference. >>>=20 >>> Stephen, the sets of initial values were chosen from those used >>> in practice by Microsoft and Google in real deployments. >>=20 >> Genuine questions: do you aim to have interop between those=20 >> deployments? What if I wanted to write code that'd interop with >> msft or google? >>=20 >> S. >>=20 >>>=20 >>> About "otp", there are existing use cases for indicating that an=20 >>> OTP was used. I'm not aware of any of these use cases where the >>> distinction between TOTP and HOTP is important. Thus, having=20 >>> "otp" now makes sense, where having "hotp" and "totp" now >>> doesn't. >>>=20 >>> Stephen, this may seem like splitting hairs, but the registry=20 >>> instructions for "Specification Document(s)" are about having a=20 >>> reference for the document where the Authentication Method=20 >>> Reference Name (such as "otp") is defined. In all cases for the=20 >>> initial values, this is the RFC-to-be, so the registry >>> instructions are satisfied. If someone were, for instance, to >>> define the string "hotp", it would be incumbent on the person >>> requesting its registration to provide a URL to the document >>> where the string "hotp" is defined. Also having a reference to >>> RFC 4226 in that document would be a good thing, but that isn't >>> what the registry instructions are about. >>>=20 >>> All that said, I can look at also finding appropriate references=20 >>> for the remaining values that don't currently have them. >>> (Anyone got a good reference for password or PIN to suggest, for=20 >>> instance?) >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- From: Anthony Nadalin Sent: Wednesday, >>> February 1, 2017 4:10 PM To: Stephen Farrell=20 >>> ; Mike Jones=20 >>> ; joel jaeggli ;=20 >>> The IESG Cc: oauth-chairs@ietf.org;=20 >>> draft-ietf-oauth-amr-values@ietf.org; oauth@ietf.org Subject: RE: >>> [OAUTH-WG] Stephen Farrell's Discuss on=20 >>> draft-ietf-oauth-amr-values-05: (with DISCUSS) >>>=20 >>> NIST asked for the addition of IRIS (as they are seeing more use=20 >>> of IRIS over retina due to the accuracy of iris) as they have=20 >>> been doing significant testing on various iris devices and >>> continue to do so, here is a report that NIST released=20 >>> http://2010-2014.commerce.gov/blog/2012/04/23/nist-iris-recognition-r= eport-evaluates-needle-haystack-search-capability.html >>> >>> >>> >>> > >>>=20 -----Original Message----- From: Stephen Farrell >>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, February 1,=20 >>> 2017 2:26 PM To: Mike Jones ; joel=20 >>> jaeggli ; The IESG Cc:=20 >>> oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org;=20 >>> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss=20 >>> on draft-ietf-oauth-amr-values-05: (with DISCUSS) >>>=20 >>>=20 >>> Hi Mike, >>>=20 >>> On 01/02/17 17:00, Mike Jones wrote: >>>> Thanks for the discussion, Stephen. >>>>=20 >>>> To your point about "otp", the working group discussed this >>>> very point. They explicitly decided not to introduce "hotp" >>>> and "totp" identifiers because no one had a use case in which >>>> the distinction mattered. >>>=20 >>> Then I'm not following why adding "otp" to the registry now is a=20 >>> good plan. >>>=20 >>> If there's a use-case now, then adding an entry with a good=20 >>> reference to the relevant spec seems right. >>>=20 >>> If there's no use-case now, then not adding it to the registry=20 >>> seems right. (Mentioning it as a possible future entry would be=20 >>> fine.) >>>=20 >>> I think the same logic would apply for all the values that this=20 >>> spec adds to the registry. Why is that wrong? >>>=20 >>>> Others can certainly introduce those identifiers and register=20 >>>> them if they do have such a use case, once the registry has >>>> been established. But the working group wanted to be >>>> conservative about the identifiers introduced to prime the >>>> registry, and this is such a case. >>>>=20 >>>> What identifiers to use and register will always be a balancing >>>> act. You want to be as specific as necessary to add practical=20 >>>> and usable value, but not so specific as to make things=20 >>>> unnecessarily brittle. >>>=20 >>> Eh... don't we want interop? Isn't that the primary goal here? >>>=20 >>>> While some might say there's a difference between serial number >>>> ranges of particular authentication devices, going there is=20 >>>> clearly in the weeds. On the other hand, while there used to >>>> be an "eye" identifier, Elaine Newton of NIST pointed out that >>>> there are significant differences between retina and iris >>>> matching, so "eye" was replaced with "retina" and "iris". >>>> Common sense informed by actual data is the key here. >>>=20 >>> That's another good example. There's no reference for "iris." If=20 >>> that is used in some protocol, then what format(s) are expected >>> to be supported? Where do I find that spec? If we can answer >>> that, then great, let's add the details. If not, then I'd suggest >>> we omit "iris" and leave it 'till later to add an entry for that. >>> And again, including text with "iris" as an example is just fine, >>> all I'm asking is that we only add the registry entry if we can >>> meet the same bar that we're asking the DE to impose on later=20 >>> additions. >>>=20 >>> And the same for all the others... >>>=20 >>> Cheers, S. >>>=20 >>>=20 >>>>=20 >>>> The point of the registry requiring a specification reference >>>> is so people using the registry can tell where the identifier >>>> is defined. For all the initial values, that requirement is=20 >>>> satisfied, since the reference will be to the new RFC. I >>>> think that aligns with the point that Joel was making. >>>>=20 >>>> Your thoughts? >>>>=20 >>>> -- Mike >>>>=20 >>>> -----Original Message----- From: OAuth=20 >>>> [mailto:oauth-bounces@ietf.org] On Behalf Of Stephen Farrell=20 >>>> Sent: Wednesday, February 1, 2017 7:03 AM To: joel jaeggli=20 >>>> ; The IESG Cc:=20 >>>> oauth-chairs@ietf.org; draft-ietf-oauth-amr-values@ietf.org;=20 >>>> oauth@ietf.org Subject: Re: [OAUTH-WG] Stephen Farrell's >>>> Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) >>>>=20 >>>>=20 >>>>=20 >>>> On 01/02/17 14:58, joel jaeggli wrote: >>>>> On 1/31/17 8:26 AM, Stephen Farrell wrote: >>>>>> Stephen Farrell has entered the following ballot position >>>>>> for draft-ietf-oauth-amr-values-05: Discuss >>>>>>=20 >>>>>> When responding, please keep the subject line intact and=20 >>>>>> reply to all email addresses included in the To and CC >>>>>> lines. (Feel free to cut this introductory paragraph, >>>>>> however.) >>>>>>=20 >>>>>>=20 >>>>>> Please refer to=20 >>>>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>>> for more information about IESG DISCUSS and COMMENT >>>>>> positions. >>>>>>=20 >>>>>>=20 >>>>>> The document, along with other ballot positions, can be >>>>>> found here:=20 >>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > >>>>>>=20 --------------------------------------------------------------------- >>>>>>=20 >>>>>>=20 >>>=20 >>>>>>=20 >> - >>>>>> DISCUSS:=20 >>>>>> ------------------------------------------------------------------= --- >>>>>> >>>>>> >>> >>>>>> >> >>>>>> > >>>>>>=20 - >>>>>>=20 >>>>>> This specification seems to me to break it's own rules. You >>>>>> state that registrations should include a reference to a=20 >>>>>> specification to improve interop. And yet, for the strings >>>>>> added here (e.g. otp) you don't do that (referring to >>>>>> section 2 will not improve interop) and there are different >>>>>> ways in which many of the methods in section 2 can be done. >>>>>> So I think you need to add a bunch more references. >>>>>=20 >>>>> Not clear to me that the document creating the registry >>>>> needs to adhere to the rules for further allocations in order >>>>> to prepoulate the registry. that is perhaps an appeal to >>>>> future consistency. >>>>=20 >>>> Sure - I'm all for a smattering of inconsistency:-) >>>>=20 >>>> But I think the lack of specs in some of these cases could=20 >>>> impact on interop, e.g. in the otp case, they quote two RFCs >>>> and yet only have one value. That seems a bit broken to me, so >>>> the discuss isn't really about the formalism. >>>>=20 >>>> S. >>>>=20 >>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --------------ms060104020408060905030808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDIw MDQ1MDFaMC8GCSqGSIb3DQEJBDEiBCAt1ufhvN04ErlW2Izy3nY9ErAWpoTRioq+Cc9EQvKQ 3jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAuT7t+UxfNQBl7LyNsCUymt8LNxt6i7Md45nTYXcQIN3DOsA9Xi9zu 624SCNEkGwAuGmEXMCNlIBo97PwBcAk25nwTld/ytHok282xXyBhXPlqMmhFIs4x4QWxM0ej cDVU0tzh2nWvAwXlwTRcL3BOJ9t9uAzs2A52PBAMfYo7u+ZDSFZ+6iW5fqrU2QvMQ4qj0yJD VJ9yiU8FF6HFHyanNhqvWTxWrTh1elxCjuPHKqFp+tdXK29Aj3by4T+kQYWXOgjxjm25xf1s zxikfsUPHa5/dMXlBMAs8t+wTqLSJ/iO2aPDE5DLUvEQMynvyMD6pqUKF82UAG0RST13blVw AAAAAAAA --------------ms060104020408060905030808-- From zhangyunqi.cs@gmail.com Wed Feb 1 18:36:50 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49262129623 for ; Wed, 1 Feb 2017 18:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkpd_hqeHdoL for ; Wed, 1 Feb 2017 18:36:48 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F05512948F for ; Wed, 1 Feb 2017 18:36:48 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id r141so67558521wmg.1 for ; Wed, 01 Feb 2017 18:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3OoxMr05lbCkRXxJctzZs1lUVwnftFFMYnnrZq3fn4A=; b=SR/uj3h+7RV/KNuNk5fcq+mxYgcH1g68Clb+dZrne4S9lD89N+t0o0PPwOQ1jjogy4 8vkX1mQOid8bB0YVezyYRr4jgVQ+CnFmiGkFu926JByBWGptDZYEsZGtgndn9Ch+KUW2 agFIaAJaBSjdRSKabEgCweASv63eBor9QgmKyJuEioTOygLr6NdzvRScqdLOTCFFt/u1 tvr8RNNmwa/UkFMaMMOFCodqDNv85TdM6MrGc6z/kVMVgYVNYJa0/c9suFk49PwTYswu Dlum8FBrB5qjrJ24S+QGgiV1oj/vDYq/lNgkCrpcRuWreW5Zn4RPVeF/q+JFTNPPY1ga HRCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3OoxMr05lbCkRXxJctzZs1lUVwnftFFMYnnrZq3fn4A=; b=SzSgu7hnubf402wxumX5MXaSvnnkG15CNYyaMIG76uAdq610qcRnIPJJV1pdNORJT1 rOyzz3y22I3QGes9JpMG2TRhXg0DH9Lotzw1cWgiXfH7nt4E98UtHcRqbWMdygR3jLnz VbCozRD+F4Htpk7POaOeS/rMm8TCp4xryvaTh6tkSx7LVLhq23pRe3xSt1YeZ8xx/He3 em1XH8nC5W1M+OmQ8H8nrcn7ITzF77vRNa4z4voJ4lxt2GZG7OQ+tolpJJF9a85xztnG nAOcEl1GRdA0MaPtgpKwhV2HdPvb9iO6cFe9sFwUhvkZYE/BNKWeWJwl23sDqg8GdAxf g1TQ== X-Gm-Message-State: AIkVDXLoxL0wY1+EW+gCtOLeGqf0gu9FuJShMO5I0kgyKOIxK6CHGT0NaJgODF6u+WiNwNpZh2FYDYvg5biruw== X-Received: by 10.223.148.2 with SMTP id 2mr5654887wrq.75.1486003006440; Wed, 01 Feb 2017 18:36:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.154.194 with HTTP; Wed, 1 Feb 2017 18:36:45 -0800 (PST) From: Yunqi Zhang Date: Wed, 1 Feb 2017 21:36:45 -0500 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0d22f05590c9054783097d Archived-At: Subject: [OAUTH-WG] OAuth for institutional users X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 02:37:52 -0000 --94eb2c0d22f05590c9054783097d Content-Type: text/plain; charset=UTF-8 Hi all, I'm working on a set of API endpoints to allow institutions to manage their users and records, and their users to read their own records. Specifically, each institution will get a {client_id} and a {secret} after registering with us, which allows them to create users under its institution using [POST https://hostname/users/]. Then the institution can also insert records for each user using [POST https://hostname/users/:user_id/]. Once a user has been created, he/she can read his/her own records using [GET https://hostname/users/:user_id/]. In this process, there are two types of authentications I would like to achieve, which I'm thinking about using oauth. However, I am super new on oauth and have four questions. Institution authentication (e.g., company FOO will have READ and WRITE access to https://hostname/ to create users under its own institution, insert records for specific users): (1) Since this part of the system will be created and run by the institution, this should be a "client credential grant" using {client_id} and {secret} of the institution, correct? End-user authentication (e.g., user John Doe of company FOO will have READ access to https://hostname/users/:john_doe_user_id/ to read his own personal records): (2) Because this part of the system will probably run on the web/mobile app created by company FOO, this should be a "resource owner credential grant" using {username}, {password} of the specific user, correct? (3) Because I am allow two types of different authentications, which will use two types of different {access_token}s I assume, would that be something weird (or hard to build) under the oauth model? (4) What if the web/mobile app created by a subset of the companies already has its own authentication and does not want to create another password for each of its users, what should I do? For example, company FOO has its own authentication for its web/mobile app and does not want to bother creating another password for each of its user (i.e., requires only {username}), whereas company BAR would like to create another password for each user (i.e., requires {username} and {password}). What kind of authentication model should I use for a scenario like this? Thank you very much for your help! Yunqi --94eb2c0d22f05590c9054783097d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm working on a set of API= endpoints to allow institutions to manage their users and records, and the= ir users to read their own records.

Specifically, = each institution will get a {client_id} and a {secret} after registering wi= th us, which allows them to create users under its institution using [POST = https://hostname/users/]. Then the = institution can also insert records for each user using [POST https://hostname/users/:user_id/]. Once= a user has been created, he/she can read his/her own records using [GET https://hostname/users/:user_id/= ].

In this process, there are two types of aut= hentications I would like to achieve, which I'm thinking about using oa= uth. However, I am super new on oauth and have four questions.
Institution authentication (e.g., company FOO will have READ a= nd WRITE access to https://hostname/ to c= reate users under its own institution, insert records for specific users): = (1) Since this part of the system will be created and run by the institutio= n, this should be a "client credential grant" using {client_id} a= nd {secret} of the institution, correct?

End-user = authentication (e.g., user John Doe of company FOO will have READ access to= https://hostname/use= rs/:john_doe_user_id/ to read his own personal records): (2) Because th= is part of the system will probably run on the web/mobile app created by co= mpany FOO, this should be a "resource owner credential grant" usi= ng {username}, {password} of the specific user, correct?

(3) Because I am allow two types of different authentications, which= will use two types of different {access_token}s I assume, would that be so= mething weird (or hard to build) under the oauth model?

(4) What if the web/mobile app created by a subset of the companies a= lready has its own authentication and does not want to create another passw= ord for each of its users, what should I do? For example, company FOO has i= ts own authentication for its web/mobile app and does not want to bother cr= eating another password for each of its user (i.e., requires only {username= }), whereas company BAR would like to create another password for each user= (i.e., requires {username} and {password}). What kind of authentication mo= del should I use for a scenario like this?

Thank y= ou very much for your help!

Yunqi
--94eb2c0d22f05590c9054783097d-- From nobody Wed Feb 1 19:33:49 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4036129620; Wed, 1 Feb 2017 19:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=teamtelstra.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXOwf0oNTs4t; Wed, 1 Feb 2017 19:33:41 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) (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 AD8F3126579; Wed, 1 Feb 2017 19:33:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,323,1477918800"; d="scan'208";a="136163235" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 02 Feb 2017 14:33:36 +1100 X-IronPort-AV: E=McAfee;i="5700,7163,8426"; a="412181385" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbvi.tcif.telstra.com.au with ESMTP; 02 Feb 2017 14:33:36 +1100 Received: from wsapp5870.srv.dir.telstra.com (10.75.139.12) by wsmsg3757.srv.dir.telstra.com (172.49.40.85) with Microsoft SMTP Server (TLS) id 8.3.485.1; Thu, 2 Feb 2017 14:33:36 +1100 Received: from wsapp5584.srv.dir.telstra.com (10.75.131.20) by wsapp5870.srv.dir.telstra.com (10.75.139.12) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 2 Feb 2017 14:33:34 +1100 Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.101.125) by wsapp5584.srv.dir.telstra.com (10.75.131.20) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Thu, 2 Feb 2017 14:33:34 +1100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P7lQzFJMfC021B80kYGTvSPk8Hmr/kceJAZY6hwue8Q=; b=feu0Rmpb2M5T5pvCBYA8ebLJfnqsomtoa/UxH4DBEdrX7z0kGUmq2mnNQ77g9eUv4a9acfBm2OukxxnCDXLMW8rSjyxqDggliu6Z9soxGDlopP8RcNoHVuAqSrMy2/hkN3OXwwCAf5NLzAw1B4RvYFcrA8P98mQ6B7Esk9zdIwQ= Received: from SYXPR01MB1615.ausprd01.prod.outlook.com (10.175.209.15) by SYXPR01MB1616.ausprd01.prod.outlook.com (10.175.209.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Thu, 2 Feb 2017 03:33:31 +0000 Received: from SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) by SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) with mapi id 15.01.0888.019; Thu, 2 Feb 2017 03:33:31 +0000 From: "Manger, James" To: Mike Jones , Stephen Farrell , Anthony Nadalin , "joel jaeggli" , The IESG Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) Thread-Index: AQHSe97eBIMrMKaVGkSUvkZhrKFklqFUP6sAgAABIQCAACDtgIAAWs6AgAAdOACAAAMugIAAAKeAgAAA3wCAAAB0gIAAAK0AgAABNICAABu3sA== Date: Thu, 2 Feb 2017 03:33:31 +0000 Message-ID: References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie> <268ffcf0-2f90-049e-1a3c-03b39d62c338@cs.tcd.ie> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; x-originating-ip: [203.41.142.254] x-ms-office365-filtering-correlation-id: 9b691198-b185-43dd-f3eb-08d44b1c42cf x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SYXPR01MB1616; x-microsoft-exchange-diagnostics: 1; SYXPR01MB1616; 7:8UUsW55LlZYBH6NVyAIiUWipPJFJ5it0/VUHuUfnrlljvzhILq0QtoKLIFzvVOXaJAXia1+ZJIvLGeWNva1dF+k8IHCVCr9GG2+73YIhpCFP0D3xeK+SsqYLpR+UrkvHiFN/GyrgEGaiHfUEL4xkBc97E0IOYJfuckvPu1UyCZxnLwDDSMy6uLugfLg2vOP6n1MrCV3wz/o5hbh/PM3OUDdkyzU3CqyHz/wrdhYzegdyVna/mWuZc9GedqZomegsaysYurbNaRb2A+wE+xLtcr0ILLP3NG0oxFSgZlldQo2tK8b4laN9nQwM8/MUEjfckbx9zVnNyjp6qopyIstW29myA4jWyw0JyUjx3Hoix63Cy4JrLIXJD2/gL9MTWsEKIOFBsx3pO/pJUsJ5ymia2bhGIAwIbxZXjtzLy0W+qawsxjRbk6b1SJ3C/vIiym/Hv41elJHLdwh1d591FLqpcgf14R1iPd93dbyEq6oqhhmw2NEXGVFMFq8nJlAzrhSNZEWoEM5Z+lWaOl/GwvyYJcUaKGjXylHojEoksZmeXqLSK0FstRgUg4L4NZKtchOz x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:SYXPR01MB1616; BCL:0; PCL:0; RULEID:; SRVR:SYXPR01MB1616; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(39450400003)(199003)(189002)(54356999)(50986999)(2900100001)(8676002)(53936002)(81156014)(68736007)(97736004)(2950100002)(101416001)(92566002)(42882006)(5660300001)(81166006)(8936002)(7696004)(230783001)(551544002)(122556002)(93886004)(5001770100001)(2561002)(33656002)(229853002)(38730400001)(102836003)(3846002)(4326007)(99286003)(6116002)(86362001)(76176999)(106116001)(9686003)(54906002)(55016002)(8666007)(2421001)(6506006)(106356001)(6436002)(3660700001)(7736002)(74316002)(305945005)(3280700002)(2906002)(189998001)(1511001)(77096006)(25786008)(66066001)(105586002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:SYXPR01MB1616; H:SYXPR01MB1615.ausprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 03:33:31.7684 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1616 X-OriginatorOrg: team.telstra.com Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 03:33:43 -0000 > You can call me lazy if you want. Some of them are so well known, such a= s "password" or "PIN" it didn't seem worthwhile to try to track down a refe= rence.=20 "password" and "PIN" are so well known, yet curiously they are quite differ= ent as "amr" values. "pwd" is merely defined as "password-based authentication". But "pin" is not just a short numeric password. The "pin" amr value means a= uthentication uses a (probably device-specific) crypto key that was unlocke= d with a local PIN or pattern and has defences against repeated guesses. As a relying party, seeing "pin" means if it is an attacker they needed the= user's device and to know their PIN (within a couple of guesses), and ther= e shouldn't be much systemic risk from server-side password DB breaches. Seeing "pwd" means if it is an attacker they needed to guess the user's pas= sword or get it from a password breach. Whether it is was a user-chosen pas= sword with zero restrictions and susceptible to dictionary attack, or a 12-= char upper+lower+numeric+symbol not-in-common-list changed-monthly not-in-l= ast-20 password, you don't know. As to the "Specification Document(s)" column in the registry, it would bett= er to leave it blank for those values where the spec provides nothing beyon= d the Name and Description that are in the registry anyway (such as "iris",= "fpt", "geo", iris", "pwd", "retina", "sc", "sms", "tel", "user", "vbm"). In some other cases the only thing in the spec, but not the registry, is a = reference to another spec so wouldn't it be better to put that reference in= the registry directly. For instance, { kba; Knowledge-based authentication= ; [NIST.800-63-2] [ISO29115]}. Similarly for "hwk", "rba", "otp", "swk", "w= ia". -- James Manger From nobody Wed Feb 1 23:10:04 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1591293EB for ; Wed, 1 Feb 2017 23:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.955 X-Spam-Level: X-Spam-Status: No, score=-6.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tKIwcdJh3yc for ; Wed, 1 Feb 2017 23:10:02 -0800 (PST) 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 B4DB3128B44 for ; Wed, 1 Feb 2017 23:10:01 -0800 (PST) Received: from [192.168.91.173] ([195.149.223.239]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MXr3H-1cvxS53UwB-00WoFK for ; Thu, 02 Feb 2017 08:09:59 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Thu, 2 Feb 2017 08:09:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q8NDIiNocBi4P9mrOTu45Oo4NgoWvCoh3" X-Provags-ID: V03:K0:CFnYRQ0AjQGz8bXwzo4WNC1ZgWIiq27t5ERgzKMblGra8liZQDa 8wkmqCA9QFh8CDLPZQ1tc5NXy5cg0bpymFd8aI1jX0QbHhslO6s1FRdyHWZavYjTSEzSSl/ h3m35mWSjlpIWcI+LNbFEraLa9sb/ScjSj9i22iuzIRcnsNg0DHkTCVBkhpPciFyD01j0GF 0oSnLpLZ3XbTCpff2IUrg== X-UI-Out-Filterresults: notjunk:1;V01:K0:yQiZ39JzgLg=:1DnZJTli3YFLYivSIlwn99 Zt3kjRYHe4XyGVHiGabkNVME59Wt0WGnBY54expN6G1cRSSKaJ9OMgjNxqrvpEgaDxkB+iAD6 MQYzN+Zpofmwo/ZWr0ioxIqGNTXCYXHWziFtBDBb4xg+auWP4lWeLa4rtLPqka7vwzY9SIi0k FT/Mq0FeWOTTcReahLM7NM3cd5uwsDMw+BH+8WhRSJ9Yf0WtLu/y2m7z5ObInTgdqpEgFDD0D IPDS1OC610utNbkH+qGjSHxDJpLenZal/AK6H+kdLnoJKFlnnt1yilebUbf/eEkaKRJjazyeA k6gRI4h9iUVp8R2ZXS6oMlje8fxQxZA8QP5D8VCHZl2jSClJmYTV5z4udBtknix4PJHQu5KtR XEOsbxeA7hibgmKBNhpnrO+AlAbG06klhkFSdu0mssnS0wJp/0quJbA2bAF0f3vCAGZd66drS Y1TCVclidur4tQ6ErFj/YPWcHJTBCaY90neC7iuPsID60+mMWgI30rvoBrOjWu0A19Yys4UkU B5H26Dvp8qzJpG2e1RFwpOHCOHGM+Av3xdEAUXq+MTvTCEvL/2ucaFRPbsq7sidWXcETIi2X7 k4EZtTqpnEeGSeDmn0iY4RF3yXsLtAGK9r6QjN32uKs+qZ8wMlThR/yjxsBYJvEulEz6Va1Du 6UCNryW/46osVMfBTSjAtz1/uweY/nKgdYZZWH1VROdvZimGWZUPNWWV8rlQmnvxsqzOdhff4 E1PsnWAMa6p5DOZkLkdb9+UQsmxeVzSO+bEZ77antgwbqPyuiHU+iYloL2E= Archived-At: Subject: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 07:10:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Q8NDIiNocBi4P9mrOTu45Oo4NgoWvCoh3 Content-Type: multipart/mixed; boundary="XSqVGsaeTcFHMJph7qIVXnrnqnNhpbW3W"; protected-headers="v1" From: Hannes Tschofenig To: "oauth@ietf.org" Message-ID: Subject: Call for adoption: OAuth Security Topics --XSqVGsaeTcFHMJph7qIVXnrnqnNhpbW3W Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, this is the call for adoption of the 'OAuth Security Topics' document following the positive call for adoption at the last IETF meeting in Seoul. Here is the document: https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 The intention with this document is to have a place to collect discussions and conclusions around OAuth 2.0 security and to reference the actual solution specifications. Please let us know by Feb 16th whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Ciao Hannes & Derek --XSqVGsaeTcFHMJph7qIVXnrnqnNhpbW3W-- --Q8NDIiNocBi4P9mrOTu45Oo4NgoWvCoh3 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 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYkttFAAoJEGhJURNOOiAtWwsIAIvOqG+6LfZWQfRfC4dI1Py+ Xj1jS2ubgoYCb1kqu+AruNzINCHZkOL+sY+bwTJ8sqKIs6xrE6yD4MN6F+N/NVHj zomzSmI+SR5vsoqQUCgqdWpQHTZcpiTX0Kk0dkzYY1RmngIYanT5sdNL1dvLaTZw 10SQySb+S/w47mVK0+1EKOOMOXAr3rLPGc7rpwT9/PfNX0jMpmJWb9KJvKRAY1qX 2mt+eNno379TvH2/VYaRXJTXtxBhbMd6Qjw2nymajQWD/slOyZJSALW/aDmPgaJj JBp1S60eyHmgQxk9eFI55sSaoQPgTIvC2MijvBisJwbfG8I+0xPK4v2yMo37Lw0= =YRPz -----END PGP SIGNATURE----- --Q8NDIiNocBi4P9mrOTu45Oo4NgoWvCoh3-- From nobody Thu Feb 2 00:05:48 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34811129406; Thu, 2 Feb 2017 00:05:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148602274618.28299.16863291767893795433.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 00:05:46 -0800 Archived-At: Cc: oauth-chairs@ietf.org, draft-ietf-oauth-amr-values@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 08:05:46 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-oauth-amr-values-05: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is a fine document and I support its publication. However I have a small set of issues that I would like to discuss first. Are non ASCII names needed? (This is a protocol element, not a human readable string, so non ASCII is not needed). Are ASCII spaces allowed in names? More generally: what do you call printable character? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 6.1: suggestion to first describe IANA registration policy, then describe restrictions on registered names. Otherwise the current text doesn't flow well. I am also agreeing with Stephen's DISCUSS. From nobody Thu Feb 2 05:32:18 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276CE129449; Thu, 2 Feb 2017 05:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdMHVVaKGowe; Thu, 2 Feb 2017 05:32:14 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 7B81C129442; Thu, 2 Feb 2017 05:32:14 -0800 (PST) X-AuditID: 1209190f-3a3ff700000038d4-e9-589334dcc122 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id B6.32.14548.CD433985; Thu, 2 Feb 2017 08:32:13 -0500 (EST) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v12DWCtN015875; Thu, 2 Feb 2017 08:32:12 -0500 Received: from W92EXEDGE5.EXCHANGE.MIT.EDU (w92exedge5.exchange.mit.edu [18.7.73.22]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id v12DWBec013409; Thu, 2 Feb 2017 08:32:11 -0500 Received: from W92EXHUB12.exchange.mit.edu (18.7.73.21) by W92EXEDGE5.EXCHANGE.MIT.EDU (18.7.73.22) with Microsoft SMTP Server (TLS) id 14.3.339.0; Thu, 2 Feb 2017 08:31:26 -0500 Received: from OC11EXPO33.exchange.mit.edu ([169.254.1.80]) by W92EXHUB12.exchange.mit.edu ([18.7.73.21]) with mapi id 14.03.0339.000; Thu, 2 Feb 2017 08:32:10 -0500 From: Thomas Hardjono To: Aaron Parecki Thread-Topic: [OAUTH-WG] Decentralized OAuth2.0 -- FW: New Version Notification for draft-hardjono-oauth-decentralized-00.txt Thread-Index: AQHSfOVlyUPOs0QsG0eqL+eCJmsJw6FVMCIAgACGjGQ= Date: Thu, 2 Feb 2017 13:32:10 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342AC1CD85BE@OC11EXPO33.exchange.mit.edu> References: <5E393DF26B791A428E5F003BB6C5342AC1CD7488@OC11EXPO33.exchange.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.38.117.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPKsWRmVeSWpSXmKPExsUixCmqrHvXZHKEwf9DAhbnVrlZ3J67ks3i 5NtXbA7MHkuW/GTyaJiZFsAUxWWTkpqTWZZapG+XwJXR1vCHueC9dMWkmyvZGxjfinUxcnJI CJhILG/Zx9zFyMUhJNDGJPG44xwbhLOfUaJn1g5GCOcoo8Tl5ZNYIZxtjBKPfs9nh3BWMkpM ndDKBDKMTUBDou1HLzuILSKgKnGtsY0RxGYWSJSY9HsaWFxYoE7i6KRXzBA19RJTu/+yQdhW Er3/rrCA2CwCKhJrJt0Fq+EVCJJov3wbatl0Ronrm3eCFXEKBEp0bDgOtoBRQEzi+6k1TBDL xCVuPZnPBPGdoMSi2XuYIWwxiX+7HrJB2IoSDX83sELU60gs2P2JDcLWlli28DXUYkGJkzOf sExglJiFZOwsJC2zkLTMQtKygJFlFaNsSm6Vbm5iZk5xarJucXJiXl5qka6JXm5miV5qSukm RnA8SvLvYJzT4H2IUYCDUYmHN0NsUoQQa2JZcWXuIUZJDiYlUd4pWpMjhPiS8lMqMxKLM+KL SnNSiw8xSnAwK4nw3tEDyvGmJFZWpRblw6SkOViUxHnFNRojhATSE0tSs1NTC1KLYLIyHBxK ErzbjYEaBYtS01Mr0jJzShDSTBycIMN5gIZngdTwFhck5hZnpkPkTzEqSonzWoIkBEASGaV5 cL3gdMnuKfaKURzoFWHeGyBVPMBUC9f9CmgwE9Dgn48ngQwuSURISTUwrvILmblv20Y5udi5 N/Rd7c+4z790+K7pcXup6qapFw5GJU/gO6a+eXfKszzBFap1cw6auUnuc8kv2bsym3e1LFOm n0lMabj49ItWDTen7Un62HfkbNsqHb7GlyfM17ww+ZBqb1f1bdJ0W853gk9++Un/rdjkeVrs 4O1L9WX93OsXWPp3Mp6+rsRSnJFoqMVcVJwIAHGi/P5yAwAA Archived-At: Cc: "oauth@ietf.org" , "oauth-chairs@ietf.org" Subject: Re: [OAUTH-WG] Decentralized OAuth2.0 -- FW: New Version Notification for draft-hardjono-oauth-decentralized-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 13:32:16 -0000 What's needed would be (a) contracts servers that can talk to one another, = (b) addition of pub-keys to some well known endpoints, and (c) some actual = contracts with actual legal prose :-) The contract server could be treated as a protected endpoint (e.g. at the A= S), but since contract agreement is a 2-way handshake we may need to add so= me new message flows. /thomas/ ________________________________________ From: Aaron Parecki [aaron@parecki.com] Sent: Wednesday, February 01, 2017 7:26 PM To: Thomas Hardjono Cc: oauth@ietf.org; oauth-chairs@ietf.org Subject: Re: [OAUTH-WG] Decentralized OAuth2.0 -- FW: New Version Notificat= ion for draft-hardjono-oauth-decentralized-00.txt The introduction sounds great, especially acknowledging the problems due to= "the predominance of the web single sign-on model as the basis for the use= r interaction"... but is there a summary of what this actually describes? I= see a lot of boilerplate text, and defining some new terms, but I don't ac= tually know what I would implement after reading this. ---- Aaron Parecki aaronparecki.com @aaronpk On Wed, Feb 1, 2017 at 3:48 PM, Thomas Hardjono > wrote: Folks, This may be of interest. Its forward-looking, I know. Appreciate any commen= ts on the draft. Best. /thomas/ ________________________________________ From: internet-drafts@ietf.org [internet-d= rafts@ietf.org] Sent: Wednesday, February 01, 2017 6:39 PM To: Thomas Hardjono Subject: New Version Notification for draft-hardjono-oauth-decentralized-00= .txt A new version of I-D, draft-hardjono-oauth-decentralized-00.txt has been successfully submitted by Thomas Hardjono and posted to the IETF repository. Name: draft-hardjono-oauth-decentralized Revision: 00 Title: Decentralized Service Architecture for OAuth2.0 Document date: 2017-02-01 Group: Individual Submission Pages: 21 URL: https://www.ietf.org/internet-drafts/draft-hardjono-oauth-d= ecentralized-00.txt Status: https://datatracker.ietf.org/doc/draft-hardjono-oauth-decen= tralized/ Htmlized: https://tools.ietf.org/html/draft-hardjono-oauth-decentrali= zed-00 Abstract: This document proposes an alternative service architecture for user- centric control of the sharing of resources, such as personal data, using the decentralized peer-to-peer computing paradigm. The term 'control' is used here to denote the full capacity of the user to freely select (i) the entities with whom to share resources (e.g. data), and (ii) the entities which provide services implementing user-controlled resource sharing. The peer-to-peer service architecture uses a set of computing nodes called OAuth2.0 Nodes (ON) that are part of a peer-to-peer network as the basis for the decentralized service architecture. Each OAuth2.0 Nodes is assumed to have the capability to provide AS-services, RS-services and Client-services. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Feb 2 07:05:24 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39400129459; Thu, 2 Feb 2017 07:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv0hmJ57b9yz; Thu, 2 Feb 2017 07:05:21 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0103.outbound.protection.outlook.com [104.47.38.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71238129453; Thu, 2 Feb 2017 07:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rII94THAAKSsKMoWMs6M6ZphmjYdgC57pe5qK/6wLAY=; b=o3o0TEOoN4TU4zXkgwWYssMnEqSGRT4PZVugxEOopF1q77a53GDb5ebePI6/+3nAaxrlYg9O7JGZupsPbh3329DmLYHBRpd2RYlzToC7sx3x8wGB3S5mJNZtwRoqDG6IL38yGmT1rkclsUwziueFGK4DnlxFpJgbW9vE7cVCiFg= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2354.namprd03.prod.outlook.com (10.166.74.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 15:05:17 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0874.021; Thu, 2 Feb 2017 15:05:17 +0000 From: Mike Jones To: Alexey Melnikov , The IESG Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT) Thread-Index: AQHSfSstZ8gA/avhoUyAuPTivWAUwqFV0P+Q Date: Thu, 2 Feb 2017 15:05:17 +0000 Message-ID: References: <148602274618.28299.16863291767893795433.idtracker@ietfa.amsl.com> In-Reply-To: <148602274618.28299.16863291767893795433.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.95.25] x-ms-office365-filtering-correlation-id: 705c65c8-b62c-49dd-c1fe-08d44b7ce65c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR03MB2354; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2354; 7:gAXsN2/S/VqoHtl3hXU/Dq2wnkFBVWEnJV4gucduxXXs7G0Cx+ubRhZbmkEJcTO6q/JkN0j/I2fOatecI/dpHBjm/bOATpV+75OzNMbUyZyr6kWRYicTPosR9A1vau9I74vw25ljeAVy6kHB68gRVLIaDnMZUR4CPYxV0F4OOGpV7c1Bhzk5py2Oe7ZDS5pcAxj8ioYj2VGK6xM3paopyMk1tHVGAS4tzfrWUMkxpwcwFT7vhjMpdG6Y/5VU59QOAKAfUD3TiOWH+mtj1qNWKPXDsRREGskeZxN+D50Gn0JB7q8gvq7n4/7tN9VPDyW41i1ZWzbiqg7Gu972Uu01XoCeiXibE7P36Cu8oR3Hn1LQFxI0csBoWLjBDRsjhBhWmgogX/nL+5VWd44OlZ35rHtU6IAmkpEWC10pqwJBxvhNqJzGKfBU0tKDKTUhlfU9uoaHE2J52ks9wu2k/zE6G6CgOiTPtj+CJvYg+bPyu6gMnp35a/gHxpU1swTGJUvP2NHQVU34J+EXClWpLLWyfFR5uRkgDqw/kgzciV+r5AEWsGeMfFreB5yznuhYTGWl x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(131327999870524)(248736688235697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123558025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:BN3PR03MB2354; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2354; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39450400003)(39410400002)(39850400002)(377454003)(189002)(199003)(13464003)(6116002)(53936002)(5001770100001)(97736004)(10090500001)(3846002)(3280700002)(8990500004)(4326007)(2906002)(5005710100001)(106116001)(10290500002)(230783001)(102836003)(7736002)(106356001)(305945005)(105586002)(5660300001)(2950100002)(7696004)(6306002)(3660700001)(77096006)(25786008)(76176999)(189998001)(6436002)(8666007)(6506006)(229853002)(74316002)(55016002)(38730400001)(99286003)(9686003)(54906002)(54356999)(8676002)(122556002)(86362001)(68736007)(81156014)(101416001)(81166006)(86612001)(8936002)(33656002)(66066001)(92566002)(2900100001)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2354; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 15:05:17.6367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2354 Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:05:23 -0000 SSdkIGJlIE9LIGxpbWl0aW5nIHRoZSBwcm90b2NvbCBlbGVtZW50cyB0byB1c2luZyBBU0NJSSBj aGFyYWN0ZXJzLCBpZiB0aGF0IHdvdWxkIGJlIHRoZSBJRVNHJ3MgcHJlZmVyZW5jZS4NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFsZXhleSBNZWxuaWtvdiBbbWFpbHRvOmFh bWVsbmlrb3ZAZmFzdG1haWwuZm1dIA0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIsIDIwMTcg MTI6MDYgQU0NClRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRmLW9h dXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9m ZW5pZ0BnbXgubmV0Pjsgb2F1dGgtY2hhaXJzQGlldGYub3JnOyBIYW5uZXMuVHNjaG9mZW5pZ0Bn bXgubmV0OyBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogQWxleGV5IE1lbG5pa292J3MgRGlzY3Vz cyBvbiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6ICh3aXRoIERJU0NVU1MgYW5kIENP TU1FTlQpDQoNCkFsZXhleSBNZWxuaWtvdiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxv dCBwb3NpdGlvbiBmb3INCmRyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlcy0wNTogRGlzY3Vzcw0K DQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFu ZCByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0Mg bGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93 ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3Rh dGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFs b25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMv DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGlzIGlz IGEgZmluZSBkb2N1bWVudCBhbmQgSSBzdXBwb3J0IGl0cyBwdWJsaWNhdGlvbi4gSG93ZXZlciBJ IGhhdmUgYSBzbWFsbCBzZXQgb2YgaXNzdWVzIHRoYXQgSSB3b3VsZCBsaWtlIHRvIGRpc2N1c3Mg Zmlyc3QuDQoNCkFyZSBub24gQVNDSUkgbmFtZXMgbmVlZGVkPyAoVGhpcyBpcyBhIHByb3RvY29s IGVsZW1lbnQsIG5vdCBhIGh1bWFuIHJlYWRhYmxlIHN0cmluZywgc28gbm9uIEFTQ0lJIGlzIG5v dCBuZWVkZWQpLiBBcmUgQVNDSUkgc3BhY2VzIGFsbG93ZWQgaW4gbmFtZXM/IE1vcmUgZ2VuZXJh bGx5OiB3aGF0IGRvIHlvdSBjYWxsIHByaW50YWJsZSBjaGFyYWN0ZXI/DQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KSW4gU2VjdGlvbiA2LjE6IHN1Z2dlc3Rp b24gdG8gZmlyc3QgZGVzY3JpYmUgSUFOQSByZWdpc3RyYXRpb24gcG9saWN5LCB0aGVuIGRlc2Ny aWJlIHJlc3RyaWN0aW9ucyBvbiByZWdpc3RlcmVkIG5hbWVzLiBPdGhlcndpc2UgdGhlIGN1cnJl bnQgdGV4dCBkb2Vzbid0IGZsb3cgd2VsbC4NCg0KSSBhbSBhbHNvIGFncmVlaW5nIHdpdGggU3Rl cGhlbidzIERJU0NVU1MuDQoNCg0K From nobody Thu Feb 2 07:07:09 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE938129453; Thu, 2 Feb 2017 07:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=N/c6zdCm; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=VxSGKj73 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYTU5A5SlvF4; Thu, 2 Feb 2017 07:07:02 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703CB129450; Thu, 2 Feb 2017 07:07:02 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DD76720BDF; Thu, 2 Feb 2017 10:07:01 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 02 Feb 2017 10:07:01 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=JaKPliWMelWTBiILq0eTuf9L/f s=; b=N/c6zdCmKzN6cVcFLZBZ3ic4ZV/45oj1WZH1GEQ6htPKo9OfGuVGApOu/3 6LWQUptZMPvUBY7fiA/jFIv95PmGZC1/zSnURWJcJQ+/bLgWnqEsYnb3sQ7me304 DKaxioD/Vwz8QR5+IR2kd06HMLAqeEGkpBv2V4L3cQZmwzudg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=Ja KPliWMelWTBiILq0eTuf9L/fs=; b=VxSGKj73C+2lXtGfVLfqjtggQqJKMu2J+X E+rhLS8VU8baJefsvsIzZhPdk8nH/QljzmJuxXksEk8zbtK/FqmcNyoOZpedtpwD jBa216efT69H3ikmJynKCo1545p3DNQGlUSCen0vXlEwrAb3f4pjN3kWao3mYqdA vnwDIli7M= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8B0A66ABF9; Thu, 2 Feb 2017 10:07:01 -0500 (EST) Message-Id: <1486048021.331167.868093568.44D5380B@webmail.messagingengine.com> From: Alexey Melnikov To: Mike Jones , The IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e9b51b02 In-Reply-To: Date: Thu, 02 Feb 2017 15:07:01 +0000 References: <148602274618.28299.16863291767893795433.idtracker@ietfa.amsl.com> Archived-At: Cc: oauth-chairs@ietf.org, draft-ietf-oauth-amr-values@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:07:04 -0000 Hi Mike, On Thu, Feb 2, 2017, at 03:05 PM, Mike Jones wrote: > I'd be OK limiting the protocol elements to using ASCII characters, if > that would be the IESG's preference. I think that would be much simpler for everybody. I still want to confirm that spaces are allowed in names. Can you confirm? > > -----Original Message----- > From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm] > Sent: Thursday, February 2, 2017 12:06 AM > To: The IESG > Cc: draft-ietf-oauth-amr-values@ietf.org; Hannes Tschofenig > ; oauth-chairs@ietf.org; > Hannes.Tschofenig@gmx.net; oauth@ietf.org > Subject: Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: > (with DISCUSS and COMMENT) > > Alexey Melnikov has entered the following ballot position for > draft-ietf-oauth-amr-values-05: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This is a fine document and I support its publication. However I have a > small set of issues that I would like to discuss first. > > Are non ASCII names needed? (This is a protocol element, not a human > readable string, so non ASCII is not needed). Are ASCII spaces allowed in > names? More generally: what do you call printable character? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In Section 6.1: suggestion to first describe IANA registration policy, > then describe restrictions on registered names. Otherwise the current > text doesn't flow well. > > I am also agreeing with Stephen's DISCUSS. > > From nobody Thu Feb 2 07:52:39 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A727129688 for ; Thu, 2 Feb 2017 07:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.554 X-Spam-Level: X-Spam-Status: No, score=-8.554 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, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwWr5XDf2tDG for ; Thu, 2 Feb 2017 07:52:37 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 05E74129686 for ; Thu, 2 Feb 2017 07:52:36 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v12FqYrq026775 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Feb 2017 15:52:35 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v12FqY9P002623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Feb 2017 15:52:34 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v12FqXVn015942; Thu, 2 Feb 2017 15:52:34 GMT Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Feb 2017 07:52:33 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-A619C385-DC7D-4F4F-8F67-3782EE746C66 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Thu, 2 Feb 2017 07:52:32 -0800 Content-Transfer-Encoding: 7bit Message-Id: <318C729C-3374-47B9-BF7E-F5F2F81EAC33@oracle.com> References: To: Yunqi Zhang X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth for institutional users X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 15:52:38 -0000 --Apple-Mail-A619C385-DC7D-4F4F-8F67-3782EE746C66 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable You are headed down the road to a very big domain called identity management= and provisioning.=20 You might want to look at SCIM (RFC7643, 7644) for a restful api pattern. SCIM is usually OAuth enabled but the scopes/rights have not yet been standa= rdized. There is however some obvious access control patterns that apply fro= m the old ldap directory world. =20 Phil > On Feb 1, 2017, at 6:36 PM, Yunqi Zhang wrote: >=20 > Hi all, >=20 > I'm working on a set of API endpoints to allow institutions to manage thei= r users and records, and their users to read their own records. >=20 > Specifically, each institution will get a {client_id} and a {secret} after= registering with us, which allows them to create users under its institutio= n using [POST https://hostname/users/]. Then the institution can also insert= records for each user using [POST https://hostname/users/:user_id/]. Once a= user has been created, he/she can read his/her own records using [GET https= ://hostname/users/:user_id/]. >=20 > In this process, there are two types of authentications I would like to ac= hieve, which I'm thinking about using oauth. However, I am super new on oaut= h and have four questions. >=20 > Institution authentication (e.g., company FOO will have READ and WRITE acc= ess to https://hostname/ to create users under its own institution, insert r= ecords for specific users): (1) Since this part of the system will be create= d and run by the institution, this should be a "client credential grant" usi= ng {client_id} and {secret} of the institution, correct? >=20 > End-user authentication (e.g., user John Doe of company FOO will have READ= access to https://hostname/users/:john_doe_user_id/ to read his own persona= l records): (2) Because this part of the system will probably run on the web= /mobile app created by company FOO, this should be a "resource owner credent= ial grant" using {username}, {password} of the specific user, correct? >=20 > (3) Because I am allow two types of different authentications, which will u= se two types of different {access_token}s I assume, would that be something w= eird (or hard to build) under the oauth model? >=20 > (4) What if the web/mobile app created by a subset of the companies alread= y has its own authentication and does not want to create another password fo= r each of its users, what should I do? For example, company FOO has its own a= uthentication for its web/mobile app and does not want to bother creating an= other password for each of its user (i.e., requires only {username}), wherea= s company BAR would like to create another password for each user (i.e., req= uires {username} and {password}). What kind of authentication model should I= use for a scenario like this? >=20 > Thank you very much for your help! >=20 > Yunqi > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-A619C385-DC7D-4F4F-8F67-3782EE746C66 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
You are headed down the road to a very= big domain called identity management and provisioning. 

You might want= to look at SCIM (RFC7643, 7644) for a restful api pattern.

SCIM is usually= OAuth enabled but the scopes/rights have not yet been standardized. There i= s however some obvious access control patterns that apply from the old ldap d= irectory world.  

Phil

On Feb 1, 2017, at 6:36 PM,= Yunqi Zhang <zhangyunqi.cs@gm= ail.com> wrote:

Hi all,

I'm working on a set of API endpoints to al= low institutions to manage their users and records, and their users to read t= heir own records.

Specifically, each institution wi= ll get a {client_id} and a {secret} after registering with us, which allows t= hem to create users under its institution using [POST https://hostname/users/]. Then the institution can also in= sert records for each user using [POST https://hostname/users/:user_id/]. Once a user has been created,= he/she can read his/her own records using [GET https://hostname/users/:user_id/].

=
In this process, there are two types of authentications I would like to= achieve, which I'm thinking about using oauth. However, I am super new on o= auth and have four questions.

Institution authentic= ation (e.g., company FOO will have READ and WRITE access to https://hostname/ to create users under its own institutio= n, insert records for specific users): (1) Since this part of the system wil= l be created and run by the institution, this should be a "client credential= grant" using {client_id} and {secret} of the institution, correct?

End-user authentication (e.g., user John Doe of company FOO= will have READ access to https://hostname/users/:john_doe_user_id/ to read his own personal r= ecords): (2) Because this part of the system will probably run on the web/mo= bile app created by company FOO, this should be a "resource owner credential= grant" using {username}, {password} of the specific user, correct?

(3) Because I am allow two types of different authenticatio= ns, which will use two types of different {access_token}s I assume, would th= at be something weird (or hard to build) under the oauth model?
(4) What if the web/mobile app created by a subset of the compa= nies already has its own authentication and does not want to create another p= assword for each of its users, what should I do? For example, company FOO ha= s its own authentication for its web/mobile app and does not want to bother c= reating another password for each of its user (i.e., requires only {username= }), whereas company BAR would like to create another password for each user (= i.e., requires {username} and {password}). What kind of authentication model= should I use for a scenario like this?

Thank you v= ery much for your help!

Yunqi
____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-A619C385-DC7D-4F4F-8F67-3782EE746C66-- From nobody Thu Feb 2 10:05:14 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A11D1294E4; Thu, 2 Feb 2017 10:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_3BTm3zKzxI; Thu, 2 Feb 2017 10:05:06 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0090.outbound.protection.outlook.com [104.47.36.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695EE129409; Thu, 2 Feb 2017 10:05:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=847G0E6d/KNNXnJEEVxFEnCov3PbgEWdsf98ZKiSS1s=; b=AbvZgocT6nKYPZIVrhKoDz14IVzxvyxChJmEohzPJjLAeSIOJAhSLiUlNlRt52A3ANyOypss8YQgqBpZ9+8Be+RegLjOvtN0RUHXtNWSfHY1aIQcOqpykOKBa+Eu140wNo5c2okHqAbTGp3ji4clRcIdwePf2CSOaIXAoJjBzsY= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2354.namprd03.prod.outlook.com (10.166.74.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.12; Thu, 2 Feb 2017 18:05:04 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0874.021; Thu, 2 Feb 2017 18:05:04 +0000 From: Mike Jones To: Alexey Melnikov , The IESG Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT) Thread-Index: AQHSfSstZ8gA/avhoUyAuPTivWAUwqFV0P+QgAAArYCAADBacA== Date: Thu, 2 Feb 2017 18:05:04 +0000 Message-ID: References: <148602274618.28299.16863291767893795433.idtracker@ietfa.amsl.com> <1486048021.331167.868093568.44D5380B@webmail.messagingengine.com> In-Reply-To: <1486048021.331167.868093568.44D5380B@webmail.messagingengine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:4::36] x-ms-office365-filtering-correlation-id: 27f2b5b7-d1d9-4f18-841c-08d44b960393 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR03MB2354; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2354; 7:6d2LjR0fx8wSoUh/AOAONtqEa4hdGN1HDL1b3lrL02HzceWCRm03f/xbI6nnJ28JjQZeNtqLbTgKvGX1EEjMQjQB78jRl1gia2DJmazLOuxBohIdn7c7VY+5HSRztVoNRwkpBJePbIK6+7lXh/pMIiKPcCTdZcwm+OEl/02uiloaxz2nZge/esL80m1DGKewmyM9gxA0BADPnl82o4tfYK1a/we6ixMhH7MtNY7WqOD73DKOUBUPiqEuLtmjCmknGpnqmZWhmAc6Wlg6LmPcq0wjk7c8aLhpPl7N5YkgPoKtecPGSbG4H8xMNayo/C14h2XIg1G/7le+LRtgKPgBnQGYXIRKEtloSLaqVCFoZd6iOqvBv8DlWvD/2wTZxBcNbwADRKlj6Eq6oIGbxf8dglrLuYeCSgfWtYSSShoimVlg7N45eukkTcxSt3jwv2+lR/T0Nno7FJaSYgAnAZyvRR3U40qmv31uO5flI1qfb759PXly2+CoxoPu0WQ6LaxEbRdfxC0c1vFTfRhyHHpSfnsWqtapEj9MXr7Q7Tu/dt7Tl2FrY38z9N1ViDXiBRFF x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(131327999870524)(248736688235697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123558025)(20161123555025)(20161123562025)(20161123560025)(6072148)(6042181); SRVR:BN3PR03MB2354; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2354; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(51444003)(199003)(13464003)(24454002)(6116002)(5001770100001)(53936002)(97736004)(10090500001)(3280700002)(8990500004)(5005710100001)(2906002)(4326007)(106116001)(102836003)(230783001)(7736002)(10290500002)(106356001)(305945005)(105586002)(5660300001)(2950100002)(7696004)(6306002)(3660700001)(77096006)(25786008)(76176999)(189998001)(8666007)(6436002)(6506006)(229853002)(74316002)(55016002)(38730400001)(54906002)(9686003)(99286003)(54356999)(8676002)(86362001)(122556002)(68736007)(81156014)(86612001)(81166006)(101416001)(8936002)(33656002)(2900100001)(92566002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2354; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 18:05:04.1988 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2354 Archived-At: Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 18:05:08 -0000 SSB3YXMgcGxhbm5pbmcgdG8gc3RheSB3aXRoIHRoZSBjaGFyYWN0ZXJzIHNwZWNpZmllZCBpbiA2 LjEgKGEpIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFtci12 YWx1ZXMtMDUjc2VjdGlvbi02LjE6DQoNCiAgIGEuICByZXF1aXJlIHRoYXQgQXV0aGVudGljYXRp b24gTWV0aG9kIFJlZmVyZW5jZSB2YWx1ZXMgYmVpbmcNCiAgICAgICByZWdpc3RlcmVkIHVzZSBv bmx5IHByaW50YWJsZSBBU0NJSSBjaGFyYWN0ZXJzIGV4Y2x1ZGluZyBkb3VibGUNCiAgICAgICBx dW90ZSAoJyInKSBhbmQgYmFja3NsYXNoICgnXCcpICh0aGUgVW5pY29kZSBjaGFyYWN0ZXJzIHdp dGggY29kZQ0KICAgICAgIHBvaW50cyBVKzAwMjEsIFUrMDAyMyB0aHJvdWdoIFUrMDA1QiwgYW5k IFUrMDA1RCB0aHJvdWdoIFUrMDA3RSksDQoNClRoYXQgZXhjbHVkZXMgc3BhY2UuICBUaGF0J3Mg dGhlIHNldCB0YWtlbiBmcm9tIFJGQyA3NjM4LCBTZWN0aW9uIDYgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzc2Mzgjc2VjdGlvbi02LCB3aGljaCBpcyBhIHZlcnkgcmVsYXRlZCB1c2Fn ZS4NCg0KU3BhY2UgaXMgZXhjbHVkZWQgYmVjYXVzZSBzb21ldGltZXMgaW4gT0F1dGggbWVzc2Fn ZXMsIHZhbHVlcyBhcmUgcmVwcmVzZW50ZWQgYXMgc3BhY2Utc2VwYXJhdGVkIHN0cmluZ3MuDQoN CgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGV4ZXkg TWVsbmlrb3YgW21haWx0bzphYW1lbG5pa292QGZhc3RtYWlsLmZtXSANClNlbnQ6IFRodXJzZGF5 LCBGZWJydWFyeSAyLCAyMDE3IDc6MDcgQU0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiBkcmFmdC1pZXRm LW9hdXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNj aG9mZW5pZ0BnbXgubmV0Pjsgb2F1dGgtY2hhaXJzQGlldGYub3JnOyBvYXV0aEBpZXRmLm9yZw0K U3ViamVjdDogUmU6IEFsZXhleSBNZWxuaWtvdidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vYXV0 aC1hbXItdmFsdWVzLTA1OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpIaSBNaWtlLA0K DQpPbiBUaHUsIEZlYiAyLCAyMDE3LCBhdCAwMzowNSBQTSwgTWlrZSBKb25lcyB3cm90ZToNCj4g SSdkIGJlIE9LIGxpbWl0aW5nIHRoZSBwcm90b2NvbCBlbGVtZW50cyB0byB1c2luZyBBU0NJSSBj aGFyYWN0ZXJzLCBpZiANCj4gdGhhdCB3b3VsZCBiZSB0aGUgSUVTRydzIHByZWZlcmVuY2UuDQoN CkkgdGhpbmsgdGhhdCB3b3VsZCBiZSBtdWNoIHNpbXBsZXIgZm9yIGV2ZXJ5Ym9keS4NCg0KSSBz dGlsbCB3YW50IHRvIGNvbmZpcm0gdGhhdCBzcGFjZXMgYXJlIGFsbG93ZWQgaW4gbmFtZXMuIENh biB5b3UgY29uZmlybT8NCg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogQWxleGV5IE1lbG5pa292IFttYWlsdG86YWFtZWxuaWtvdkBmYXN0bWFpbC5mbV0NCj4gU2Vu dDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIsIDIwMTcgMTI6MDYgQU0NCj4gVG86IFRoZSBJRVNHIDxp ZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzQGlldGYub3Jn OyBIYW5uZXMgVHNjaG9mZW5pZyANCj4gPEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ+OyBvYXV0 aC1jaGFpcnNAaWV0Zi5vcmc7IA0KPiBIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0OyBvYXV0aEBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBBbGV4ZXkgTWVsbmlrb3YncyBEaXNjdXNzIG9uIGRyYWZ0LWll dGYtb2F1dGgtYW1yLXZhbHVlcy0wNToNCj4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4g DQo+IEFsZXhleSBNZWxuaWtvdiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCj4gZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTA1OiBEaXNjdXNzDQo+IA0K PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFu ZCByZXBseSB0byBhbGwgDQo+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5k IENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCANCj4gdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdy YXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVmZXIgdG8gDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9y ZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0K PiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25z LCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IERJU0NVU1M6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IFRoaXMgaXMgYSBmaW5lIGRvY3Vt ZW50IGFuZCBJIHN1cHBvcnQgaXRzIHB1YmxpY2F0aW9uLiBIb3dldmVyIEkgaGF2ZSANCj4gYSBz bWFsbCBzZXQgb2YgaXNzdWVzIHRoYXQgSSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgZmlyc3QuDQo+ IA0KPiBBcmUgbm9uIEFTQ0lJIG5hbWVzIG5lZWRlZD8gKFRoaXMgaXMgYSBwcm90b2NvbCBlbGVt ZW50LCBub3QgYSBodW1hbiANCj4gcmVhZGFibGUgc3RyaW5nLCBzbyBub24gQVNDSUkgaXMgbm90 IG5lZWRlZCkuIEFyZSBBU0NJSSBzcGFjZXMgYWxsb3dlZCANCj4gaW4gbmFtZXM/IE1vcmUgZ2Vu ZXJhbGx5OiB3aGF0IGRvIHlvdSBjYWxsIHByaW50YWJsZSBjaGFyYWN0ZXI/DQo+IA0KPiANCj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBJbiBTZWN0 aW9uIDYuMTogc3VnZ2VzdGlvbiB0byBmaXJzdCBkZXNjcmliZSBJQU5BIHJlZ2lzdHJhdGlvbiBw b2xpY3ksIA0KPiB0aGVuIGRlc2NyaWJlIHJlc3RyaWN0aW9ucyBvbiByZWdpc3RlcmVkIG5hbWVz LiBPdGhlcndpc2UgdGhlIGN1cnJlbnQgDQo+IHRleHQgZG9lc24ndCBmbG93IHdlbGwuDQo+IA0K PiBJIGFtIGFsc28gYWdyZWVpbmcgd2l0aCBTdGVwaGVuJ3MgRElTQ1VTUy4NCj4gDQo+IA0K From nobody Thu Feb 2 11:11:16 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36C312959D for ; Thu, 2 Feb 2017 11:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4HoPvlQxLlK for ; Thu, 2 Feb 2017 11:11:12 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0128.outbound.protection.outlook.com [104.47.32.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392E8129541 for ; Thu, 2 Feb 2017 11:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HfOeUy2HOF5GaKOHY8s5X8lohkuehU6v9fWaeD/74eM=; b=b6KEd5nautUdMWXwZumoZ6bdJAp7p8rPJp8KEwD5WeiZ4Bz5xmP22i1pJrX+BWH/IBjuYIPZOvkMf+bqlP/5NqqDt63Z9OdSgqioWEGl1hi8vVLsYLuXnsgY6Y74f3shpGIzHVFs7/9HwP2Uo8QBefjzPxw5qB6qLYR0Zqau5Uo= Received: from SN1PR0301MB2029.namprd03.prod.outlook.com (10.163.226.27) by SN1PR0301MB2032.namprd03.prod.outlook.com (10.163.226.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Thu, 2 Feb 2017 19:11:09 +0000 Received: from SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) by SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) with mapi id 15.01.0860.027; Thu, 2 Feb 2017 19:11:09 +0000 From: Anthony Nadalin To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Call for adoption: OAuth Security Topics Thread-Index: AQHSfSNklg6OLVxbOk+PWUOxKxjXA6FWFePA Date: Thu, 2 Feb 2017 19:11:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8:2::220] x-ms-office365-filtering-correlation-id: c1fc06b2-bc33-48f6-6c7a-08d44b9f3f4b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:SN1PR0301MB2032; x-microsoft-exchange-diagnostics: 1; SN1PR0301MB2032; 7:7eAJNXE+LQvhkVoUZqi6Ly4fTFpE8Nhjg+jpP6NpqXQv7HZTIi/T098tVHlV3SI4a2ZVqBwCMdH/nBbdzrIW6CgqPlVgk+qsFiV+nrecd+SRHixifoVEQGXqCjq4zt5ZIkal5F8WWU1udohA5eIPuBCqFJ+RaUAzOeMyerGAarIolNkKBjkwKfr3u69TuJBOFnGCHGAhsK//hkGqyRHquPlPXE0nR9QZLvLsJmMJFnFNCdzXP+2WadOodpEgP2tiSnBuFUGnY00ff3NjkLPwZielUBzcUEUrX7nA6R7qWCjE+3TU4cjTbjgl/GdDlZwCQdCdA4qB6nfxyf01PwMJKmv5sjY46fWUGsxyyLG8jf74MXD3FpJv2+IO0FReNi3iRw4wV9A2reKo9cV0XcX150AuZfraG6ULba39/95L9uU1yyWxONbN1i1PA8/+q8xhE0usdmCHP0Ph0TZ3fAMrPUa2yN8hgizw9jtWm9j0w9JqeD5iXzz7SbN6m1cXDNEu8ae1ixWQmZVxQsWfEy+KS+MZGpnDscSDLKoVcWmbTQdi2UwM+69ITFmb/IRSJmj8 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(189930954265078)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(6072148); SRVR:SN1PR0301MB2032; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB2032; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39450400003)(39850400002)(39410400002)(13464003)(53754006)(189002)(199003)(377454003)(7736002)(86612001)(101416001)(10290500002)(5001770100001)(305945005)(92566002)(189998001)(50986999)(97736004)(76176999)(5005710100001)(86362001)(10090500001)(54356999)(122556002)(107886002)(33656002)(2900100001)(105586002)(53936002)(106116001)(74316002)(106356001)(8990500004)(68736007)(81156014)(81166006)(8936002)(8676002)(2950100002)(3660700001)(15650500001)(2906002)(102836003)(3280700002)(6116002)(7696004)(6436002)(229853002)(5660300001)(6506006)(38730400001)(25786008)(9686003)(77096006)(99286003)(55016002)(6306002)(2501003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB2032; H:SN1PR0301MB2029.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 19:11:09.8231 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB2032 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:11:15 -0000 SSB3b3VsZCBiZSBpbiBmYXZvciBvZiB0aGlzIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgSGFubmVzIFRzY2hvZmVuaWcNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMSwgMjAxNyAx MToxMCBQTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBbT0FVVEgtV0ddIENhbGwgZm9y IGFkb3B0aW9uOiBPQXV0aCBTZWN1cml0eSBUb3BpY3MNCg0KSGkgYWxsLA0KDQp0aGlzIGlzIHRo ZSBjYWxsIGZvciBhZG9wdGlvbiBvZiB0aGUgJ09BdXRoIFNlY3VyaXR5IFRvcGljcycgZG9jdW1l bnQgZm9sbG93aW5nIHRoZSBwb3NpdGl2ZSBjYWxsIGZvciBhZG9wdGlvbiBhdCB0aGUgbGFzdCBJ RVRGIG1lZXRpbmcgaW4gU2VvdWwuDQoNCkhlcmUgaXMgdGhlIGRvY3VtZW50Og0KaHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0 b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1sb2RkZXJzdGVkdC1vYXV0aC1zZWN1cml0eS10 b3BpY3MtMDAmZGF0YT0wMiU3QzAxJTdDdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN0NkZDJkMDRk ZjY2MmE0YmZlMzZlNTA4ZDQ0YjNhODRlNiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzYyMTYxNjIwOTgzMzgxMDEmc2RhdGE9OXRNampLdFRCUXJOVkVFcHdm TWFJSDJnVHlteUFEZGdqRUpuS1U0TVA2VSUzRCZyZXNlcnZlZD0wDQoNClRoZSBpbnRlbnRpb24g d2l0aCB0aGlzIGRvY3VtZW50IGlzIHRvIGhhdmUgYSBwbGFjZSB0byBjb2xsZWN0IGRpc2N1c3Np b25zIGFuZCBjb25jbHVzaW9ucyBhcm91bmQgT0F1dGggMi4wIHNlY3VyaXR5IGFuZCB0byByZWZl cmVuY2UgdGhlIGFjdHVhbCBzb2x1dGlvbiBzcGVjaWZpY2F0aW9ucy4NCg0KUGxlYXNlIGxldCB1 cyBrbm93IGJ5IEZlYiAxNnRoIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0byB0aGUgYWRv cHRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3JrIGluIHRo ZSBPQXV0aCB3b3JraW5nIGdyb3VwLg0KDQpDaWFvDQpIYW5uZXMgJiBEZXJlaw0KDQo= From nobody Thu Feb 2 11:18:33 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9B1129951 for ; Thu, 2 Feb 2017 11:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.93 X-Spam-Level: X-Spam-Status: No, score=-4.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DapaKSfJGWgT for ; Thu, 2 Feb 2017 11:18:30 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 90459129456 for ; Thu, 2 Feb 2017 11:18:30 -0800 (PST) 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 v12JIQHM008380 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Feb 2017 19:18:27 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v12JIPim017219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Feb 2017 19:18:26 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v12JINTV008495; Thu, 2 Feb 2017 19:18:24 GMT Received: from [10.0.1.30] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 02 Feb 2017 11:18:23 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_79987035-822C-433F-92C6-20313C437723" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: Date: Thu, 2 Feb 2017 11:18:22 -0800 Message-Id: <2406D070-8295-4664-A318-EECED08DFB90@oracle.com> References: To: Tony Nadalin X-Mailer: Apple Mail (2.3124) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:18:32 -0000 --Apple-Mail=_79987035-822C-433F-92C6-20313C437723 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 Phil Oracle Corporation, Identity Cloud Services & Identity Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Feb 2, 2017, at 11:11 AM, Anthony Nadalin = wrote: >=20 > I would be in favor of this=20 >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Wednesday, February 1, 2017 11:10 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Call for adoption: OAuth Security Topics >=20 > Hi all, >=20 > this is the call for adoption of the 'OAuth Security Topics' document = following the positive call for adoption at the last IETF meeting in = Seoul. >=20 > Here is the document: > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-lodderstedt-oauth-security-topics-00&data=3D02%7C01= %7Ctonynad%40microsoft.com%7Cdd2d04df662a4bfe36e508d44b3a84e6%7C72f988bf86= f141af91ab2d7cd011db47%7C1%7C0%7C636216162098338101&sdata=3D9tMjjKtTBQrNVE= EpwfMaIH2gTymyADdgjEJnKU4MP6U%3D&reserved=3D0 >=20 > The intention with this document is to have a place to collect = discussions and conclusions around OAuth 2.0 security and to reference = the actual solution specifications. >=20 > Please let us know by Feb 16th whether you accept / object to the = adoption of this document as a starting point for work in the OAuth = working group. >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_79987035-822C-433F-92C6-20313C437723 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1

Phil

Oracle Corporation, Identity Cloud = Services & Identity Standards
@independentid
www.independentid.com
phil.hunt@oracle.com







On Feb 2, 2017, at 11:11 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:

I = would be in favor of this

-----Original = Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig
Sent: Wednesday, February 1, 2017 11:10 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for = adoption: OAuth Security Topics

Hi all,

this is the call for adoption of the 'OAuth = Security Topics' document following the positive call for adoption at = the last IETF meeting in Seoul.

Here is the = document:
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Ftools.ietf.org%2Fhtml%2Fdraft-lodderstedt-oauth-security-topics-00&= ;data=3D02%7C01%7Ctonynad%40microsoft.com%7Cdd2d04df662a4bfe36e508d44b3a84= e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636216162098338101&sda= ta=3D9tMjjKtTBQrNVEEpwfMaIH2gTymyADdgjEJnKU4MP6U%3D&reserved=3D0
The intention with this document is to have = a place to collect discussions and conclusions around OAuth 2.0 security = and to reference the actual solution specifications.

Please let us know by Feb 16th whether you accept / object to = the adoption of this document as a starting point for work in the OAuth = working group.

Ciao
Hannes = & Derek

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

= --Apple-Mail=_79987035-822C-433F-92C6-20313C437723-- From nobody Thu Feb 2 11:19:48 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFD012996B for ; Thu, 2 Feb 2017 11:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Qyo6LV0EV78 for ; Thu, 2 Feb 2017 11:19:45 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0118.outbound.protection.outlook.com [104.47.42.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7067812996F for ; Thu, 2 Feb 2017 11:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=n+1Z/Bmeid5O+WQ2kMbVCulhkSLIybKtu02dNS4Ts/E=; b=S1mD6o4tFhrapJ1DvwfOtEj+NJ+0EwnTk/n6MdrKRB2W9/TrC2NmeXM/1SSJsisLZvkWIdciaz3cR55aJJpl+T4SeZPHqJgrwbEBH++w1++ayIYDPKI4gPsCy0iPLr+X/tMSoKtJXvWVg+yk4j+ryhaZqtq/YCMueipkWMBOMt0= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2356.namprd03.prod.outlook.com (10.166.74.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Thu, 2 Feb 2017 19:19:41 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0874.021; Thu, 2 Feb 2017 19:19:41 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Call for adoption: OAuth Security Topics Thread-Index: AQHSfSNm+gkY3I6zwESvWUrkZK3bfaFWGEbw Date: Thu, 2 Feb 2017 19:19:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:4::36] x-ms-office365-filtering-correlation-id: 9b139409-1bde-4550-e33a-08d44ba07079 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR03MB2356; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2356; 7:fsvSriyvqJ/Rx/Dq4S7h6loa1FKApeEY/ZTLgQWGx7giz4Wv5HewIKqKct5/6LtVyuf/R+ZBJF98zZeBmH18ETvREGukzOU3UGZzfh/ASIpf++xMvmENELJD3vQLacJCGSPfzu/72BJVRnNC9rlTk0jhEA1nWg/DpsxvbV7p2BqzGZo1XisxVz/AbGn10aJQ6SB1yOi4J++LB4pvYSX8yWU17ZMeXjQEWPlXymdlIShAknqNEUuVriWu0PxNValQMPjOOFH2ZLZr113O9r7G0YOQO4NsEI4Jej940xpW1N+cBV15CKA8SfBA8FtbjpXldHdzycQUerEZbE7ahTNnDx5Al3nr3Vh2hjSdt+zVPDVjFKIEVDuguqXCwGuJyiP1MOeebWd+K5v81IhMqO4LJ3KdWzbIACjXbi0TMgCqupx9SYxGpcOJZamfJ4qNcmK3QHpeXO62FX14o4YYDxLDWHyHpGYz2hpNsVeDmMtrcLNcIEoRLxgeGfmah2mi0SikOGcGrgGia4etbxwzZz4gQg66ubuPpmTh3KLmv7sCYMI= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(20161123558025)(6042181)(6072148); SRVR:BN3PR03MB2356; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2356; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(53754006)(13464003)(199003)(377454003)(189002)(6436002)(6506006)(7696004)(2501003)(7736002)(8676002)(8936002)(6116002)(305945005)(15650500001)(81156014)(81166006)(9686003)(25786008)(2900100001)(102836003)(3660700001)(55016002)(99286003)(6306002)(8990500004)(10290500002)(5660300001)(53936002)(5005710100001)(229853002)(92566002)(2950100002)(77096006)(38730400001)(10090500001)(68736007)(5001770100001)(122556002)(97736004)(189998001)(107886002)(86612001)(3280700002)(106116001)(33656002)(2906002)(76176999)(54356999)(106356001)(86362001)(74316002)(101416001)(50986999)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2356; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 19:19:41.7887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2356 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:19:47 -0000 SSBzdXBwb3J0IGFkb3B0aW9uLg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWcNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMSwg MjAxNyAxMToxMCBQTQ0KVG86IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBbT0FVVEgtV0ddIENh bGwgZm9yIGFkb3B0aW9uOiBPQXV0aCBTZWN1cml0eSBUb3BpY3MNCg0KSGkgYWxsLA0KDQp0aGlz IGlzIHRoZSBjYWxsIGZvciBhZG9wdGlvbiBvZiB0aGUgJ09BdXRoIFNlY3VyaXR5IFRvcGljcycg ZG9jdW1lbnQgZm9sbG93aW5nIHRoZSBwb3NpdGl2ZSBjYWxsIGZvciBhZG9wdGlvbiBhdCB0aGUg bGFzdCBJRVRGIG1lZXRpbmcgaW4gU2VvdWwuDQoNCkhlcmUgaXMgdGhlIGRvY3VtZW50Og0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxvZGRlcnN0ZWR0LW9hdXRoLXNlY3VyaXR5 LXRvcGljcy0wMA0KDQpUaGUgaW50ZW50aW9uIHdpdGggdGhpcyBkb2N1bWVudCBpcyB0byBoYXZl IGEgcGxhY2UgdG8gY29sbGVjdCBkaXNjdXNzaW9ucyBhbmQgY29uY2x1c2lvbnMgYXJvdW5kIE9B dXRoIDIuMCBzZWN1cml0eSBhbmQgdG8gcmVmZXJlbmNlIHRoZSBhY3R1YWwgc29sdXRpb24gc3Bl Y2lmaWNhdGlvbnMuDQoNClBsZWFzZSBsZXQgdXMga25vdyBieSBGZWIgMTZ0aCB3aGV0aGVyIHlv dSBhY2NlcHQgLyBvYmplY3QgdG8gdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBz dGFydGluZyBwb2ludCBmb3Igd29yayBpbiB0aGUgT0F1dGggd29ya2luZyBncm91cC4NCg0KQ2lh bw0KSGFubmVzICYgRGVyZWsNCg0K From nobody Thu Feb 2 11:34:11 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBA712997E for ; Thu, 2 Feb 2017 11:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmaMqeG3eewQ for ; Thu, 2 Feb 2017 11:34:07 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45CA512998A for ; Thu, 2 Feb 2017 11:34:07 -0800 (PST) X-AuditID: 1209190d-7f3ff70000006dba-fc-589389adbc8c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 41.61.28090.DA983985; Thu, 2 Feb 2017 14:34:06 -0500 (EST) 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 v12JY5Le021807 for ; Thu, 2 Feb 2017 14:34:05 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v12JY4lC008590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 2 Feb 2017 14:34:05 -0500 To: oauth@ietf.org References: <318C729C-3374-47B9-BF7E-F5F2F81EAC33@oracle.com> From: Justin Richer Message-ID: <39f411e1-da84-b25c-a894-9e0a629d6d95@mit.edu> Date: Thu, 2 Feb 2017 14:33:56 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <318C729C-3374-47B9-BF7E-F5F2F81EAC33@oracle.com> Content-Type: multipart/alternative; boundary="------------E5F871D08CFC19D36C3FE0E0" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixG6noruuc3KEwcNLrBYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt59rgUbYyumzPzN2MB4y7WLkZNDQsBE4sOfSWxdjFwcQgJt TBLrfixmgnCOMkpcfTmVEcJ5zyQx89FfFpAWYQFTiZUHzzOC2CICQhLPd/ZBdbQwSuzaupIZ JMEmoCoxfU0LE4jNK2Al8XZCPzuIzSKgIjFz2iqwQaICMRIv90DYvAKCEidnPgGyOTg4Bewk rn/3AAkzC4RJfF63jH0CI98sJFWzkKQgbFuJO3N3M0PY8hLb386BsnUlFm1bwQ4Tb946m3kB I9sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXSO93MwSvdSU0k2MoGDllOTdwfjvrtchRgEORiUe 3hPekyOEWBPLiitzDzFKcjApifJO0QIK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuGd2AyU401J rKxKLcqHSUlzsCiJ84prNEYICaQnlqRmp6YWpBbBZGU4OJQkeK90ADUKFqWmp1akZeaUIKSZ ODhBhvMADd8OUsNbXJCYW5yZDpE/xajLsW/7mZdMQix5+XmpUuK8z9uBigRAijJK8+DmgJJM wtvDpq8YxYHeEuZlBqYcIR5ggoKb9ApoCRPQkp+PJ4EsKUlESEk1MIq1fzpq/cHMtsfZ7sd5 i5y1SSI3Z6zq0mmQ22i8a9/+InP2RcZacz/7vjLmkmFjl7zOfdH3wzHWWxEHDgY9lKo9Lj6B ufidR7aH9165fzZ2C7O6wlde3Kbj2N9j4fPqS2h8V63FGR51/XkL5sRmfwjfUn38ffCrdS6O tm7cql41q1Y7+TFYKrEUZyQaajEXFScCACQw0f8NAwAA Archived-At: Subject: Re: [OAUTH-WG] OAuth for institutional users X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:34:10 -0000 This is a multi-part message in MIME format. --------------E5F871D08CFC19D36C3FE0E0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit +1 to Phil's reference to SCIM, and since it looks like you're looking to do end user authentication you should look at OpenID Connect: http://openid.net/connect/ There are a lot of ways to get an authentication protocol based on OAuth very, very wrong, and I've covered some of the big ones in an article I wrote (with the community's help) a few years ago: http://oauth.net/articles/authentication/ Furthermore, I've covered the topic in my upcoming book, OAuth 2 In Action, which you might find useful: https://www.manning.com/books/oauth-2-in-action All said, the space is not as easy as you may think it is at first and there are a lot of pitfalls. But the good news is that you're not the first to dive in here and there are a lot of really good solutions already available. -- Justin On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote: > You are headed down the road to a very big domain called identity > management and provisioning. > > You might want to look at SCIM (RFC7643, 7644) for a restful api pattern. > > SCIM is usually OAuth enabled but the scopes/rights have not yet been > standardized. There is however some obvious access control patterns > that apply from the old ldap directory world. > > Phil > > On Feb 1, 2017, at 6:36 PM, Yunqi Zhang > wrote: > >> Hi all, >> >> I'm working on a set of API endpoints to allow institutions to manage >> their users and records, and their users to read their own records. >> >> Specifically, each institution will get a {client_id} and a {secret} >> after registering with us, which allows them to create users under >> its institution using [POST https://hostname/users/]. Then the >> institution can also insert records for each user using [POST >> https://hostname/users/:user_id/]. Once a user has been created, >> he/she can read his/her own records using [GET >> https://hostname/users/:user_id/]. >> >> In this process, there are two types of authentications I would like >> to achieve, which I'm thinking about using oauth. However, I am super >> new on oauth and have four questions. >> >> Institution authentication (e.g., company FOO will have READ and >> WRITE access to https://hostname/ to create users under its own >> institution, insert records for specific users): (1) Since this part >> of the system will be created and run by the institution, this should >> be a "client credential grant" using {client_id} and {secret} of the >> institution, correct? >> >> End-user authentication (e.g., user John Doe of company FOO will have >> READ access to https://hostname/users/:john_doe_user_id/ to read his >> own personal records): (2) Because this part of the system will >> probably run on the web/mobile app created by company FOO, this >> should be a "resource owner credential grant" using {username}, >> {password} of the specific user, correct? >> >> (3) Because I am allow two types of different authentications, which >> will use two types of different {access_token}s I assume, would that >> be something weird (or hard to build) under the oauth model? >> >> (4) What if the web/mobile app created by a subset of the companies >> already has its own authentication and does not want to create >> another password for each of its users, what should I do? For >> example, company FOO has its own authentication for its web/mobile >> app and does not want to bother creating another password for each of >> its user (i.e., requires only {username}), whereas company BAR would >> like to create another password for each user (i.e., requires >> {username} and {password}). What kind of authentication model should >> I use for a scenario like this? >> >> Thank you very much for your help! >> >> Yunqi >> _______________________________________________ >> 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 --------------E5F871D08CFC19D36C3FE0E0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

+1 to Phil's reference to SCIM, and since it looks like you're looking to do end user authentication you should look at OpenID Connect:

http://openid.net/connect/

There are a lot of ways to get an authentication protocol based on OAuth very, very wrong, and I've covered some of the big ones in an article I wrote (with the community's help) a few years ago:

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

Furthermore, I've covered the topic in my upcoming book, OAuth 2 In Action, which you might find useful:

https://www.manning.com/books/oauth-2-in-action

All said, the space is not as easy as you may think it is at first and there are a lot of pitfalls. But the good news is that you're not the first to dive in here and there are a lot of really good solutions already available.

 -- Justin


On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote:
You are headed down the road to a very big domain called identity management and provisioning. 

You might want to look at SCIM (RFC7643, 7644) for a restful api pattern.

SCIM is usually OAuth enabled but the scopes/rights have not yet been standardized. There is however some obvious access control patterns that apply from the old ldap directory world.  

Phil

On Feb 1, 2017, at 6:36 PM, Yunqi Zhang <zhangyunqi.cs@gmail.com> wrote:

Hi all,

I'm working on a set of API endpoints to allow institutions to manage their users and records, and their users to read their own records.

Specifically, each institution will get a {client_id} and a {secret} after registering with us, which allows them to create users under its institution using [POST https://hostname/users/]. Then the institution can also insert records for each user using [POST https://hostname/users/:user_id/]. Once a user has been created, he/she can read his/her own records using [GET https://hostname/users/:user_id/].

In this process, there are two types of authentications I would like to achieve, which I'm thinking about using oauth. However, I am super new on oauth and have four questions.

Institution authentication (e.g., company FOO will have READ and WRITE access to https://hostname/ to create users under its own institution, insert records for specific users): (1) Since this part of the system will be created and run by the institution, this should be a "client credential grant" using {client_id} and {secret} of the institution, correct?

End-user authentication (e.g., user John Doe of company FOO will have READ access to https://hostname/users/:john_doe_user_id/ to read his own personal records): (2) Because this part of the system will probably run on the web/mobile app created by company FOO, this should be a "resource owner credential grant" using {username}, {password} of the specific user, correct?

(3) Because I am allow two types of different authentications, which will use two types of different {access_token}s I assume, would that be something weird (or hard to build) under the oauth model?

(4) What if the web/mobile app created by a subset of the companies already has its own authentication and does not want to create another password for each of its users, what should I do? For example, company FOO has its own authentication for its web/mobile app and does not want to bother creating another password for each of its user (i.e., requires only {username}), whereas company BAR would like to create another password for each user (i.e., requires {username} and {password}). What kind of authentication model should I use for a scenario like this?

Thank you very much for your help!

Yunqi
_______________________________________________
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

--------------E5F871D08CFC19D36C3FE0E0-- From nobody Thu Feb 2 11:49:58 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 857961299A8 for ; Thu, 2 Feb 2017 11:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4UN-sgC_m5E for ; Thu, 2 Feb 2017 11:49:55 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 AD1FC129996 for ; Thu, 2 Feb 2017 11:49:54 -0800 (PST) X-AuditID: 12074422-78bff70000000a5a-93-58938d60d6a2 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 (Symantec Messaging Gateway) with SMTP id 79.A4.02650.06D83985; Thu, 2 Feb 2017 14:49:52 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v12JnpNJ026702; Thu, 2 Feb 2017 14:49:52 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v12Jnodl022559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Feb 2017 14:49:51 -0500 To: Hannes Tschofenig , "oauth@ietf.org" References: From: Justin Richer Message-ID: <049d7f8f-505b-2026-5894-2a1931e635cc@mit.edu> Date: Thu, 2 Feb 2017 14:49:42 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8DFC740078C7BD718D435955" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixG6nrpvQOznCYO4hI4ulO++xWpx8+4rN gclj8ab9bB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq43zSfqaBHvOLreaUGxn9CXYycHBICJhJT Fv1j7mLk4hASaGOSOPuphQ3C2cAo8anrAFTmFpPEzs4nrCAtwgIOEvNunmQHsUUEYiUu/T0B FhcSsJI40H2cGcRmE1CVmL6mhQnE5gWK35/yigXEZhFQkfh+6yCYLSoQI/FyzyoWiBpBiZMz n4DZnALWElumngCaw8HBLBAmMbGjbAIj3ywkVbMQMiBhZgFbiTtzdzND2PIS29/OgbJ1JRZt W8EOE2/eOpt5ASPbKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1TvdzMEr3UlNJNjODgdVHawTjx n9chRgEORiUe3gLPyRFCrIllxZW5hxglOZiURHmnaAGF+JLyUyozEosz4otKc1KLDzFKcDAr ifBObAbK8aYkVlalFuXDpKQ5WJTEecU1GiOEBNITS1KzU1MLUotgsjIcHEoSvHN7gBoFi1LT UyvSMnNKENJMHJwgw3mAhjOC1PAWFyTmFmemQ+RPMSpKifNuBEkIgCQySvPgekHJJeHtYdNX jOJArwjzioNU8QATE1z3K6DBTECDfz6eBDK4JBEhJdXAOH3WHXdfjswtTrIaVo7JbL8NXkpe mMqyocDqcIjt6br8898vqN3fyViy6Ivr5+MTXXTehF6vF9jd1G54epuYAEO5+/7TAfEW+zra 9s5VXjr9XUfj6UXcj9ldrOb9ePDkR4WHJEvEzOb1X0pF57H5SLi4TL7x5ov1IxanDdyfLvCc U/+TfmnbXSWW4oxEQy3mouJEAF6bQPwJAwAA Archived-At: Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:49:57 -0000 This is a multi-part message in MIME format. --------------8DFC740078C7BD718D435955 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit +1, it's a good topic and this document is a good starting point. -- Justin On 2/2/2017 2:09 AM, Hannes Tschofenig wrote: > Hi all, > > this is the call for adoption of the 'OAuth Security Topics' document > following the positive call for adoption at the last IETF > meeting in Seoul. > > Here is the document: > https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 > > The intention with this document is to have a place to collect > discussions and conclusions around OAuth 2.0 security and to reference > the actual solution specifications. > > Please let us know by Feb 16th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------8DFC740078C7BD718D435955 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

+1, it's a good topic and this document is a good starting point.

 -- Justin


On 2/2/2017 2:09 AM, Hannes Tschofenig wrote:
Hi all,

this is the call for adoption of the 'OAuth Security Topics' document
following the positive call for adoption at the last IETF
meeting in Seoul.

Here is the document:
https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00

The intention with this document is to have a place to collect
discussions and conclusions around OAuth 2.0 security and to reference
the actual solution specifications.

Please let us know by Feb 16th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Derek




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

--------------8DFC740078C7BD718D435955-- From nobody Thu Feb 2 13:31:05 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A9B1294B6 for ; Thu, 2 Feb 2017 13:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.254 X-Spam-Level: X-Spam-Status: No, score=-6.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mx.aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNOO_UrOTU3j for ; Thu, 2 Feb 2017 13:31:03 -0800 (PST) Received: from omr-a010e.mx.aol.com (omr-a010e.mx.aol.com [204.29.186.54]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073751299DB for ; Thu, 2 Feb 2017 13:31:03 -0800 (PST) Received: from mtaout-aac01.mx.aol.com (mtaout-aac01.mx.aol.com [172.27.2.33]) by omr-a010e.mx.aol.com (Outbound Mail Relay) with ESMTP id 312563800041; Thu, 2 Feb 2017 16:31:02 -0500 (EST) Received: from [10.182.32.23] (unknown [10.182.32.23]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aac01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B4B9E38000099; Thu, 2 Feb 2017 16:31:01 -0500 (EST) To: Hannes Tschofenig , "oauth@ietf.org" References: From: George Fletcher Organization: AOL LLC Message-ID: <099e8313-a39f-2c2e-bfc8-1e14364cfaf9@aol.com> Date: Thu, 2 Feb 2017 16:31:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------775D8A73EDB73C1C8721CC50" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1486071062; bh=guIeZoDF6fI350wDOwLjRTCLpafDRxGpC7REJ0RA7Pc=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=pqe5baR5F5aMMuBRQnMlez/yBAaQPig4AehmuPP23nSYJLYxoN87GMXT3gAAyjDlX BrOISeyD6lIHT33UcSH5tS9WD7kug5ySij3m0OgdRjWGNsMe8qDq71H90WAqc8+irB 9wuN3oP9OUk+4klSs+03We+/rIiOwUNyIzA/qzTU= x-aol-sid: 3039ac1b02215893a5150934 X-AOL-IP: 10.182.32.23 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 21:31:04 -0000 This is a multi-part message in MIME format. --------------775D8A73EDB73C1C8721CC50 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit +1 for me too :) On 2/2/17 2:09 AM, Hannes Tschofenig wrote: > Hi all, > > this is the call for adoption of the 'OAuth Security Topics' document > following the positive call for adoption at the last IETF > meeting in Seoul. > > Here is the document: > https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 > > The intention with this document is to have a place to collect > discussions and conclusions around OAuth 2.0 security and to reference > the actual solution specifications. > > Please let us know by Feb 16th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------775D8A73EDB73C1C8721CC50 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit +1 for me too :)

On 2/2/17 2:09 AM, Hannes Tschofenig wrote:
Hi all,

this is the call for adoption of the 'OAuth Security Topics' document
following the positive call for adoption at the last IETF
meeting in Seoul.

Here is the document:
https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00

The intention with this document is to have a place to collect
discussions and conclusions around OAuth 2.0 security and to reference
the actual solution specifications.

Please let us know by Feb 16th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Derek




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

--------------775D8A73EDB73C1C8721CC50-- From nobody Thu Feb 2 13:33:46 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232431299F6 for ; Thu, 2 Feb 2017 13:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbwWzWSx5BtI for ; Thu, 2 Feb 2017 13:33:43 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7481299EE for ; Thu, 2 Feb 2017 13:33:43 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id x49so1314959qtc.2 for ; Thu, 02 Feb 2017 13:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xsAmrIk8xs+UCYldqUqVsyraDqg4tAhVonI7FQbun+M=; b=FG9/dBRFrvto5zNRZTbncxylZuVZATg8BrDQ6Ek7RBCb0NIcwt5TbVsicZ5BSg0AbC ttDqR13RPZUNnyiFUpzz4md9zhcHhzXlG+FAftAvEUlwM+I+d87ygabBKDd+AA/fhTcR NNJekvL0hpZDtBDeJadWQggAT6jcWdfa7g59NSmzj+ei159yiB0RB2gr0nwBFGsB44Hm KRYIeJeAIO2XuhYJMy43uYb2joedZ/v33ZLBNgeN1fpTxu4gsq0L876FkPAhBtrsy/dR C51qjFVt5kIgnH4fkmxe8njqVyaHLcry1Cfal8EYPVh1z7IWDzUuGWowvbYuj6vFPUiE HBig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xsAmrIk8xs+UCYldqUqVsyraDqg4tAhVonI7FQbun+M=; b=EzptT0KBN8ZPkn2JBmdXBu6I0aIzYflqlGD2Co+MGc8B3p6pnv1kfq2Z8B5XpfXSVr sUFmvVN08UzAvUJbYjwEwPv/ap2wBZ6k9g43LsmsZY0jjGybto3TKxG3BZ9j0KWz9kTF xXu0iw0CmjOZ9o7DiP2Zp40J4oEdPhIXArkVU7F5DwFpNM0n87Z+ybjeUaHVXulLuK/X rneRKQuFU5mRiVoAIHj8XRlJZL/rdgTmiSBL4FiqE16kHdebyu7PU/vTf4i6WAmUJ1Wm msmQ6rQLqM0N2PmOsEKTxaBXbzSeL6CXOeQ10O9tVB5I9xfgGYgez/NA7CD6ISlvEPrb 32KQ== X-Gm-Message-State: AMke39n5nK4l/WD300H1fh0j0hqTNnOuCVFPiR7bONv221IX4U/b+WIMdtW6g2wN3OV5Afh5 X-Received: by 10.55.110.6 with SMTP id j6mr11039614qkc.92.1486071222363; Thu, 02 Feb 2017 13:33:42 -0800 (PST) Received: from [192.168.86.137] ([191.115.101.85]) by smtp.gmail.com with ESMTPSA id m30sm22635373qtg.10.2017.02.02.13.33.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 13:33:41 -0800 (PST) From: John Bradley Message-Id: <541A5105-B963-4FA4-94E4-D794A73B3358@ve7jtb.com> Content-Type: multipart/signed; boundary="Apple-Mail=_01BC8EE5-4946-40DB-9F76-C3E9CFA08C6A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 2 Feb 2017 18:33:38 -0300 In-Reply-To: To: Hannes Tschofenig References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 21:33:45 -0000 --Apple-Mail=_01BC8EE5-4946-40DB-9F76-C3E9CFA08C6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am in favour of adoption. > On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > this is the call for adoption of the 'OAuth Security Topics' document > following the positive call for adoption at the last IETF > meeting in Seoul. >=20 > Here is the document: > https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 >=20 > The intention with this document is to have a place to collect > discussions and conclusions around OAuth 2.0 security and to reference > the actual solution specifications. >=20 > Please let us know by Feb 16th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_01BC8EE5-4946-40DB-9F76-C3E9CFA08C6A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILMTCCBUcw ggQvoAMCAQICEEAfBHP+tuqufC4R+F+Tu54wDQYJKoZIhvcNAQELBQAwdTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAyIENsaWVudCBDQTAeFw0xNjA4MTIy MTE5NDFaFw0xODA4MTIyMTE5NDFaMIGCMQswCQYDVQQGEwJDTDEiMCAGA1UECAwZTWV0cm9wb2xp dGFuYSBkZSBTYW50aWFnbzEWMBQGA1UEBwwNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAwwMSm9obiBC cmFkbGV5MSAwHgYJKoZIhvcNAQkBFhF2ZTdqdGJAdmU3anRiLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALhTcSiDGvVrm4hlJA8WyFcWWe0dqnuJzstQYTaF281JFOEPA/13kQYI JMXAEUcS7NvW7KdUI0tHU0N6RTo0Ilf1E1nm8No++eqHO8pFUZ/cidpv0r+1Qcl9EgrpbZ00Y7Xg pq06EZELzJAmds4QQcsTKdpLNFbVcFnM11i2Gj5VNsYgO+qPO2AS8rLHkgDWnNkc9/lA+ZK5wGiU zxPU9KnIrERoTif3Zk7KjLvFpBWYD60M/lNoHZ5zxYgmYLmvoM1TSLn4Ms57wwT5MieV2l0aqlGC 7CKNa6XyeL1B0y0wSxL3PJQS4vSLDnttZC7od2A6yjeUMyM3rQ41vqUIMc8CAwEAAaOCAcMwggG/ MA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUmA9bUmBmTYkCcZ3yYv8IRRP2nN4wHwYDVR0jBBgwFoAUmZerGDU6i1lFQ5iy cnHI9PsJzxYwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNz bC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3NjYS5jbGll bnQyLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zY2EtY2xp ZW50Mi5jcmwwHAYDVR0RBBUwE4ERdmU3anRiQHZlN2p0Yi5jb20wIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMFUGA1UdIAROMEwwDAYKKwYBBAGBtTcGATA8BgsrBgEEAYG1NwEC BTAtMCsGCCsGAQUFBwIBFh9odHRwczovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4IBAQBqcYJfFA/ITkX4L6JihqW168Wog1BOfkbPXO+wPn5G9P1NwruGfu41b70EPPwV vol+/j+qhSSrDjFyfNBsq4G45GRR6hwx0ei/bH0UW15Y63ASYPkNlj3ydCcvhw5ItWD5aYPphBx9 C7tLnQ7ow09cqt2CIgPd3W/IGri7p4hWPbdcX0oFIhJcDxmCwTcWyoVoIo4aas5gP44LPGneCoqI lXQMJinwneEnKd7rWXlzVWv7geaH3t79zARSw9ev9F4E61cDuHi+vgTFEpio7oxybqfj99yLibhX uZjReYnYbDMRiWDXduVIrIGYwmnUuD8a0b20kJgHm+FEgB6UMa9JMIIF4jCCA8qgAwIBAgIQXLZI bkcMmMZ/9oDbZErijTANBgkqhkiG9w0BAQsFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1 WhcNMzAxMjE2MDEwMDA1WjB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDIgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7g9Q jJUJI4Ss9VBqj9Y3ok4h/TIJZUc+rzj61Rv3hNB/yeEEC1fz3i/EU+MXOOGxM7KCbtCIcJxHIW/k 8RP6sPPMO4cTg7sNzfBWsYsemtY6fN/kVr2R2X+/PjvtxmAaXpGX0znvQPxaE123IMGXy0zEKHZ/ nJDZ199TP9TNn9v+1QO0AZb4oaJ7ch0DpSJa8kF5xiNFDAg9taKKSrVuPHJL9MFFYPIqwShjHg+u YEzjfxbMP2QWwamnaA9Y7fORSDNapduFlARAcDtXdMpAijiG4HKnrN323I0Ka7lDTAWyLtTDCETK sI8fzOyL0inEu1WEVpdPytm8s1rwQB4f9QIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEGMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIGA1UdHwQr MCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggrBgEFBQcBAQRa MFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggrBgEFBQcwAoYkaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQWBBSZl6sYNTqLWUVDmLJy ccj0+wnPFjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jA/BgNVHSAEODA2MDQGBFUd IAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3 DQEBCwUAA4ICAQCZQUEEzvYk9U4wNHhDu1f9QGwbzAH4m4wIKH8ZidNYwZhyoNKW041iJ002KMW9 ywYM95n4770tT45yH29vTMlZtBvz0h44KuxMLNXRCTDwvV07sT39nPjFi5MpwZaLVueNiaa1vok1 n2Wn8lLcyCltYZNGAEifM0ko/A/vvckftFIZG75RAiZHYtfnrdBGiOxyF+nHI9a33BRX5Vl/3z0+ uHZ/Y6YPbNJ7iboOFrFZBCtt+lp3WaDB62ZoBewiMmd09JrqmMJAEgw3EbfQNtaPzHPg/EOhlZik Rgd4BCrzrbIqB2RKib+gnQJt2uoJaKOaV90S9Xgs3PC837OE9CEmY6/MTTG0xpbLh2hR/rLQ3sCr H56aODeuDrQBq85lXxRbDCERDUR7FZUhHv+i1aQaY59NPu26hDd6nqksSDq2mCddpidPBuGJz9lN X2nRyGkudDuWV6gIr6AZfaYv+ggTXOcCDJZFzMhWdLC7CPvRKxQ7vTiYV+4lgqOvV9MnZc149PPt itTysq/oOv70zx7q+tyaLTa4cqFhCclhIwSwOEJiV3xqQebvmwsDX7BaXGAJZIhbdUbNr3poEgct 6uAxw2zyr69WCJmTUUhz/k1/TT/eCUZJqnMg/6mje7tiVdaUQJcBtJ6cq5+mUDNUB1fohW8EOFai zFpP/0FaP62ctTGCA04wggNKAgEBMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UE AxMaU3RhcnRDb20gQ2xhc3MgMiBDbGllbnQgQ0ECEEAfBHP+tuqufC4R+F+Tu54wCQYFKw4DAhoF AKCCAZkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMjAyMjEz MzM5WjAjBgkqhkiG9w0BCQQxFgQUEnIYSuL+S4xHXLPZZH4sd3Fjgc0wgZoGCSsGAQQBgjcQBDGB jDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3Rh cnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIg Q2xpZW50IENBAhBAHwRz/rbqrnwuEfhfk7ueMIGcBgsqhkiG9w0BCRACCzGBjKCBiTB1MQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDIgQ2xpZW50IENBAhBA HwRz/rbqrnwuEfhfk7ueMA0GCSqGSIb3DQEBAQUABIIBAGSHhgq6QFRIcgpTPqheky/vvVSnFg4B PsF8qAWdMkPpBklEOc1suWoY837OT3SinCaEuiiVflg8UAE0SLPD6kSoQaLOwdQeOvgQEcjECPvR ut99Lp5PkIjJIxPFz+pKs+DiP8eOp9NolgQ/BujrfgBONrSNILkVk9ezgh6D2oKCxrx4gtvZHzST sWvLSR/g+Ilteb93aFT8Afx8dEN1VoXH8UVh387M2bVaY1z7jfo1Ew38VSmIMADEfoxnFWFYE++c bqs8YbKdrx4oWGoHTwEUdUOq30Uwyctft6eWY+PPq7pbXyU8suAalInTqcBpCbsujtwqt8FvGstm jtQYybMAAAAAAAA= --Apple-Mail=_01BC8EE5-4946-40DB-9F76-C3E9CFA08C6A-- From nobody Thu Feb 2 13:55:42 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0491299D8 for ; Thu, 2 Feb 2017 13:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPQ8Dcl1wxX9 for ; Thu, 2 Feb 2017 13:55:40 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::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 4292C129585 for ; Thu, 2 Feb 2017 13:55:40 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id j82so398744ybg.1 for ; Thu, 02 Feb 2017 13:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dSFeB0rIjkW6uUpTyDHO/EVv614sIxP32N82ACTU/FA=; b=QThRUfnE9nTwz5TPJK4hIiBpxyC9FWSP3ppKvuXKjRCrN9H7WJLjibhI48DC04syKX 79q2sMm5vqNkv+CH2aHdS0ahgASdpRIuWsq9EUM1gO0zBlYUYCgBLJYNJF8gj5nkvCFp QNNcN1CtHWatFxMXCIB5wgrft0QhtzzwYGxPA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dSFeB0rIjkW6uUpTyDHO/EVv614sIxP32N82ACTU/FA=; b=H5gPCNUlvPAyBbSzCg/jek3X4swHqeCTQ3hBAXQS9DYT69w/mPk4Ca2IjV5iY3/nwe HsDsHsp6KgIeXGGdZtHDEWzewDjGUAmHaMymEUMoz/49uhC1g4kdMH06dMVN0zw+Rlld e8FUo1oIGExpDir0CtrkgqIQZObcUmsujoe6TySuw/4E/oph357tLRV1hO4/3CpmdsRN oFTb8hNgG9oKueT2j2JwYzrNJQnJnQxrO9rZlDnf/HuUQZ6ljMStZ0ZWJp6O/Wa/xjQV m+gqCFdwNm6UpzNoQj7gJ8OQD4Yu9d/ayRcVcVmWgGJZUNBe7ULYe72jVAeGveRC2r6m miYg== X-Gm-Message-State: AIkVDXKKwpkzHyBvThKHif/VADba9+llYAJwNp7u1J7YCs4+TYSELg1so4pCYcWI75oIzGtEuAI+JnbogIBIGhdv X-Received: by 10.37.113.137 with SMTP id m131mr3848045ybc.179.1486072539388; Thu, 02 Feb 2017 13:55:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.90.133 with HTTP; Thu, 2 Feb 2017 13:55:08 -0800 (PST) In-Reply-To: <049d7f8f-505b-2026-5894-2a1931e635cc@mit.edu> References: <049d7f8f-505b-2026-5894-2a1931e635cc@mit.edu> From: Brian Campbell Date: Thu, 2 Feb 2017 14:55:08 -0700 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a1148b424d26eb40547933965 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 21:55:41 -0000 --001a1148b424d26eb40547933965 Content-Type: text/plain; charset=UTF-8 + 1 On Thu, Feb 2, 2017 at 12:49 PM, Justin Richer wrote: > +1, it's a good topic and this document is a good starting point. > > -- Justin > > On 2/2/2017 2:09 AM, Hannes Tschofenig wrote: > > Hi all, > > this is the call for adoption of the 'OAuth Security Topics' document > following the positive call for adoption at the last IETF > meeting in Seoul. > > Here is the document:https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 > > The intention with this document is to have a place to collect > discussions and conclusions around OAuth 2.0 security and to reference > the actual solution specifications. > > Please let us know by Feb 16th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Ciao > Hannes & Derek > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1148b424d26eb40547933965 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+ 1

On Thu, Feb 2, 2017 at 12:49 PM, Justin Richer <jricher@mit.ed= u> wrote:
=20 =20 =20

+1, it's a good topic and this document is a good starting point= .

=C2=A0-- Justin


On 2/2/2017 2:09 A= M, Hannes Tschofenig wrote:
Hi all,

this is the call for adoption of the 'OAuth Security Topics' docume=
nt
following the positive call for adoption at the last IETF
meeting in Seoul.

Here is the document:
https://tools.ietf.org/html/draft-lodderstedt-oauth-security=
-topics-00

The intention with this document is to have a place to collect
discussions and conclusions around OAuth 2.0 security and to reference
the actual solution specifications.

Please let us know by Feb 16th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Ciao
Hannes & Derek




______________________________=
_________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/m=
ailman/listinfo/oauth


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


--001a1148b424d26eb40547933965-- From nobody Thu Feb 2 14:30:54 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D197812957E for ; Thu, 2 Feb 2017 14:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=willeke-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBOuwYcJMYWo for ; Thu, 2 Feb 2017 14:30:51 -0800 (PST) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::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 0170C129446 for ; Thu, 2 Feb 2017 14:30:50 -0800 (PST) Received: by mail-yb0-x232.google.com with SMTP id 123so612411ybe.3 for ; Thu, 02 Feb 2017 14:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willeke-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=r2V6dIjbwLQXB/R207gsovMu7U3k6oRSwmAWEO1MvaU=; b=bmeH+2gBSefTvY15jwSpvHCiOU3vn4RR+zNe6umsQufx0p0x8y/rgT9j99nqXnBpG5 b7GgFPn+1atHOCWaMOYQOecWdV92uMdjrIboNPSFnugq1Q/2ssy4t3dPhpG2etgkYV0R 3OPhyFFTTLKJW9kJOP8pUbZUsBg4aUPwDhfSYTqpVQcUZM+ZZ93Ti6Do5drFRS9qm/Zb QJpNGacZhzxD2+Wiew7k0Z6oeRo0wtsdeS+ee1ugj7PpdOH7UsMdcWLZr6peXmdlZOvz 8wp+REOVgm785UHdIfhwfE+XJ07FzRyfqafhPAiqfKVcsDinD4ryS2wjXQZQ0TdiMQH2 +WKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=r2V6dIjbwLQXB/R207gsovMu7U3k6oRSwmAWEO1MvaU=; b=Sl/i4oLJveBgRNxiaf6DwAWISgFOVJMCQldJvyfT90seP2XFquA9pRxGVNuap4I2D7 f/egkDVVXKdPXrq5MZfGfeaDPb4RDudC7FNDL2T/nMnV2SP4yF5CwkK6aWpKHUJVnCVX ftJ1lJf2qpIst6ty4vwBFbpbu9e79uZzcw6NgkKYanBSQexYkf1KjgW285FzU671UNa0 WoLuZzrXK8tm1BJ2Wj1Gz8BWrBz9IUQRKNSmCer9EH56RHnACyTtAYRwlQxs5L76iyrc g+qa4XmJDEhkuvs0oFsGWuoRPpFgGry01bTW+DNMb9KPodGAoH3aiaOCLUBd5QaACYX5 6cvw== X-Gm-Message-State: AIkVDXKdOPX+sNUs5gzkDqkNEbskLORjNUQ/BHXf9ZuaAUldX3ytP0KGnwKO+WvNddjWBbJvHIeT2SvdJUfM8qb+ X-Received: by 10.37.208.196 with SMTP id h187mr4420081ybg.198.1486074650078; Thu, 02 Feb 2017 14:30:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.26.5 with HTTP; Thu, 2 Feb 2017 14:30:09 -0800 (PST) In-Reply-To: <541A5105-B963-4FA4-94E4-D794A73B3358@ve7jtb.com> References: <541A5105-B963-4FA4-94E4-D794A73B3358@ve7jtb.com> From: Jim Willeke Date: Thu, 2 Feb 2017 17:30:09 -0500 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=94eb2c055382a10a60054793b774 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 22:30:53 -0000 --94eb2c055382a10a60054793b774 Content-Type: text/plain; charset=UTF-8 +! I agree this is needed. -- -jim Jim Willeke On Thu, Feb 2, 2017 at 4:33 PM, John Bradley wrote: > I am in favour of adoption. > > On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig > wrote: > > > > Hi all, > > > > this is the call for adoption of the 'OAuth Security Topics' document > > following the positive call for adoption at the last IETF > > meeting in Seoul. > > > > Here is the document: > > https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 > > > > The intention with this document is to have a place to collect > > discussions and conclusions around OAuth 2.0 security and to reference > > the actual solution specifications. > > > > Please let us know by Feb 16th whether you accept / object to the > > adoption of this document as a starting point for work in the OAuth > > working group. > > > > Ciao > > Hannes & Derek > > > > _______________________________________________ > > 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 > > --94eb2c055382a10a60054793b774 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+!=C2=A0
I agree this is needed.

--
-jim
Jim Willeke

On Thu, Feb 2, 2017 at 4:33 PM, John Bradley= <ve7jtb@ve7jtb.com> wrote:
> On Feb 2, 2017, at 4:09 AM, Ha= nnes Tschofenig <hannes.tsc= hofenig@gmx.net> wrote:
>
> Hi all,
>
> this is the call for adoption of the 'OAuth Security Topics' d= ocument
> following the positive call for adoption at the last IETF
> meeting in Seoul.
>
> Here is the document:
> https://tools.ietf.org/ht= ml/draft-lodderstedt-oauth-security-topics-00
>
> The intention with this document is to have a place to collect
> discussions and conclusions around OAuth 2.0 security and to reference=
> the actual solution specifications.
>
> Please let us know by Feb 16th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth > working group.
>
> Ciao
> Hannes & Derek
>
> __________________= _____________________________
> 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


--94eb2c055382a10a60054793b774-- From nobody Thu Feb 2 14:47:57 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB07F129584 for ; Thu, 2 Feb 2017 14:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAXNu19zOTbu for ; Thu, 2 Feb 2017 14:47:53 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 55C0B127A90 for ; Thu, 2 Feb 2017 14:47:53 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 0988678037F for ; Thu, 2 Feb 2017 23:47:50 +0100 (CET) To: oauth@ietf.org References: <318C729C-3374-47B9-BF7E-F5F2F81EAC33@oracle.com> <39f411e1-da84-b25c-a894-9e0a629d6d95@mit.edu> From: Denis Message-ID: <71435970-7138-f739-bb92-1208d44817e1@free.fr> Date: Thu, 2 Feb 2017 23:47:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <39f411e1-da84-b25c-a894-9e0a629d6d95@mit.edu> Content-Type: multipart/alternative; boundary="------------B156F25F7669F4CEF8B24D10" Archived-At: Subject: Re: [OAUTH-WG] OAuth for institutional users X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 22:47:55 -0000 This is a multi-part message in MIME format. --------------B156F25F7669F4CEF8B24D10 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Justin, Your are making the promotion of your book (OAuth 2 In Action), soon to be published. I browsed through the 23 pages of Chapter 1 that are provided as a free download. I saw the footnote from Manning Publications Co. which states: "/We welcome reader comments about anything in the manuscript/" Since Manning Publications Co. asked for it, I hope that you will be able to take into consideration some of my comments before this book is published. I will only comment on a few sentences. 1. Page 1: "The application requests authorization from the owner of the resource and receivestokens that it can use to access the resource". Such a model is rather restrictive and does not cover the general case where an application is willing to perform an operation on a resource and where the resource tells to the application which kind of attributes need to be presented by the application for that specific operation. In such a case, the resource owner is not involved in anyway at the time of the request. If this restriction remains, this should be clearly stated. 2. Page 10:" To acquire a token, the client first sends the resource owner to the authorization server in order to request that the resource owner authorize this client". This sentence is not English. You cannot "send the resource owner to the authorization server". This sentence should be rephrased. 3. Page 16: "Even worse, some of the available options in OAuth can be taken in the wrong context or not enforced properly, leading to insecure implementations. These kinds of vulnerabilities are discussed at length in the OAuth Threat Model Document and the vulnerabilities section of this book (chapters 7, 8, 9, and 10)." Bear in mind that RFC 6819 was issued four years ago (in January 2013). Collusions between servers was considered, but collusions between clients was omitted, typically the ABC attack (Alice and Bob Collusion attack). See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html You should add some text in section 7.6 to deal with the ABC attack. 4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it’s far from perfect. We will see its replacement at some point in the future, as with all things in technology, but no real contender has yet emerged as of the writing of this book. I can agree with you that "OAuth 2.0is far from perfect". Can a protocol with so many options be a "good protocol" ? Can interoperability be achieved ? I don't think so. You then say: " but no real contender has yet emerged as of the writing of this book". I would rather suggest that you delete " but no real contender has yet emerged as of the writing of this book". 5. Page 17: "OAuth assumes that the resource owner is the one that’s controlling the client". I do hope that it is not the case. The client should only be controlled by an end-user or by a local application and no one else. 6. Page 17: " OAuth isn’t defined outside of the HTTP protocol. Since OAuth 2.0 with bearer tokens provides no message signatures, is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive secrets and information are passed over the wire, and OAuth requires a transport layer mechanism such as TLS to protect these secrets". The HTTPS protocol indeed needs to be used for resource data origin authentication and confidentiality protection of the data being exchanged. However, protecting sensitive secrets and information passed over the wire using TLS does not prevent in anyway an ABC attack. TLS binding does not provide either any extra protection in case of an ABC attack. This should be stated since this is an important issue. I really wonder if you can still say: " OAuth 2.0 is a good protocol". In any case, OAuth 2.0 is not a protocol but a framework. 7. Page 18: "OAuth doesn’t define a token format". How do you want to interoperate if no token format is being defined ? IETF RFCs on the standards track are primarily intended to be used to address interoperability. 8. Page 18 "In fact, the OAuth protocol explicitly states that the content of the token is completely opaque to the client application. This is even worse. In such a case, the client will be unable to make sure that what he got in the token is really what he was asking for: nothing more and nothing less. 9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed previously, the specification is split into multiple definitions and flows, each of which has its own set of use cases. The core OAuth 2.0 specification has somewhat accurately been described as a security protocol generator, because it can be used to design the security architecture for many different use cases. As discussed in the previous section, these systems aren’t necessarily compatible with each other." This is indeed a very good description of the current mess. 10. Section 15.2 is not provided. Its title is : *Proof of possession (PoP) tokens*. I am really curious to read how you can achieve PoP in the case of an ABC attack. 11. I also observed that there is no chapter dealing with *privacy issues.* Nowadays, it is an important topic. In particular on how to prevent an authorization server to act as *Big Brother*. A section should be added to deal with privacy issues. 12. Finally a typo on page 18:"Since OAuth 2.0 with bearer tokens provides no message signatures, *is it*not meant to be used outside of HTTPS (HTTP over TLS)". Denis > +1 to Phil's reference to SCIM, and since it looks like you're looking > to do end user authentication you should look at OpenID Connect: > > http://openid.net/connect/ > > There are a lot of ways to get an authentication protocol based on > OAuth very, very wrong, and I've covered some of the big ones in an > article I wrote (with the community's help) a few years ago: > > http://oauth.net/articles/authentication/ > > Furthermore, I've covered the topic in my upcoming book, OAuth 2 In > Action, which you might find useful: > > https://www.manning.com/books/oauth-2-in-action > > All said, the space is not as easy as you may think it is at first and > there are a lot of pitfalls. But the good news is that you're not the > first to dive in here and there are a lot of really good solutions > already available. > > -- Justin > > > On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote: >> You are headed down the road to a very big domain called identity >> management and provisioning. >> >> You might want to look at SCIM (RFC7643, 7644) for a restful api pattern. >> >> SCIM is usually OAuth enabled but the scopes/rights have not yet been >> standardized. There is however some obvious access control patterns >> that apply from the old ldap directory world. >> >> Phil >> >> On Feb 1, 2017, at 6:36 PM, Yunqi Zhang > > wrote: >> >>> Hi all, >>> >>> I'm working on a set of API endpoints to allow institutions to >>> manage their users and records, and their users to read their own >>> records. >>> >>> Specifically, each institution will get a {client_id} and a {secret} >>> after registering with us, which allows them to create users under >>> its institution using [POST https://hostname/users/]. Then the >>> institution can also insert records for each user using [POST >>> https://hostname/users/:user_id/]. Once a user has been created, >>> he/she can read his/her own records using [GET >>> https://hostname/users/:user_id/]. >>> >>> In this process, there are two types of authentications I would like >>> to achieve, which I'm thinking about using oauth. However, I am >>> super new on oauth and have four questions. >>> >>> Institution authentication (e.g., company FOO will have READ and >>> WRITE access to https://hostname/ to create users under its own >>> institution, insert records for specific users): (1) Since this part >>> of the system will be created and run by the institution, this >>> should be a "client credential grant" using {client_id} and {secret} >>> of the institution, correct? >>> >>> End-user authentication (e.g., user John Doe of company FOO will >>> have READ access to https://hostname/users/:john_doe_user_id/ to >>> read his own personal records): (2) Because this part of the system >>> will probably run on the web/mobile app created by company FOO, this >>> should be a "resource owner credential grant" using {username}, >>> {password} of the specific user, correct? >>> >>> (3) Because I am allow two types of different authentications, which >>> will use two types of different {access_token}s I assume, would that >>> be something weird (or hard to build) under the oauth model? >>> >>> (4) What if the web/mobile app created by a subset of the companies >>> already has its own authentication and does not want to create >>> another password for each of its users, what should I do? For >>> example, company FOO has its own authentication for its web/mobile >>> app and does not want to bother creating another password for each >>> of its user (i.e., requires only {username}), whereas company BAR >>> would like to create another password for each user (i.e., requires >>> {username} and {password}). What kind of authentication model should >>> I use for a scenario like this? >>> >>> Thank you very much for your help! >>> >>> Yunqi >>> _______________________________________________ >>> 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 --------------B156F25F7669F4CEF8B24D10 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Justin,

Your are making the promotion of your book (OAuth 2 In Action), soon to be published.

I browsed through the 23 pages of Chapter 1 that are provided as a free download.

I saw the footnote from Manning Publications Co. which states:

"We welcome reader comments about anything in the manuscript"

Since Manning Publications Co. asked for it, I hope that you will be able to take into consideration some of my comments before this book is published.

I will only comment on a few sentences.

1. Page 1: "The application requests authorization from the owner of the resource and receives tokens that it can use to access the resource".

Such a model is rather restrictive and does not cover the general case where an application is willing to perform an operation on a resource
and where the resource tells to the application which kind of attributes need to be presented by the application for that specific operation.
In such a case, the resource owner is not involved in anyway at the time of the request. If this restriction remains, this should be clearly stated.

2. Page 10:" To acquire a token, the client first sends the resource owner to the authorization server in order to request that the resource owner authorize this client".

This sentence is not English. You cannot "send the resource owner to the authorization server". This sentence should be rephrased.

3. Page 16: "Even worse, some of the available options in OAuth can be taken in the wrong context or not enforced properly, leading to insecure implementations.
These kinds of vulnerabilities are discussed at length in the OAuth Threat Model Document and the vulnerabilities section of this book (chapters 7, 8, 9, and 10)."

Bear in mind that RFC 6819 was issued four years ago (in January 2013). Collusions between servers was considered, but collusions between clients was omitted,
typically the ABC attack (Alice and Bob Collusion attack). See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

You should add some text in section 7.6 to deal with the ABC attack.

4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it’s far from perfect. We will see its replacement at some point in the future, as with all things
in technology, but no real contender has yet emerged as of the writing of this book.

I can agree with you that "OAuth 2.0 is far from perfect". Can a protocol with so many options be a "good protocol" ? Can interoperability be achieved ?
I don't think so. You then say: " but no real contender has yet emerged as of the writing of this book". I would rather suggest that you delete
" but no real contender has yet emerged as of the writing of this book".

5. Page 17: "OAuth assumes that the resource owner is the one that’s controlling the client".

I do hope that it is not the case. The client should only be controlled by an end-user or by a local application and no one else.


6. Page 17: " OAuth isn’t defined outside of the HTTP protocol. Since OAuth 2.0 with bearer tokens provides no message signatures,
is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive secrets and information are passed over the wire, and
OAuth requires a transport layer mechanism such as TLS to protect these secrets".

The HTTPS protocol indeed needs to be used for resource data origin authentication and confidentiality protection of the data being exchanged.
However, protecting sensitive secrets and information passed over the wire using TLS does not prevent in anyway an ABC attack. TLS binding
does not provide either any extra protection in case of an ABC attack. This should be stated since this is an important issue. I really wonder
if you can still say: " OAuth 2.0 is a good protocol". In any case, OAuth 2.0 is not a protocol but a framework.

7. Page 18: "OAuth doesn’t define a token format".

How do you want to interoperate if no token format is being defined ? IETF RFCs on the standards track are primarily intended to be used to address interoperability.

8. Page 18 "In fact, the OAuth protocol explicitly states that the content of the token is completely opaque to the client application.

This is even worse. In such a case, the client will be unable to make sure that what he got in the token is really what he was asking for: nothing more and nothing less.

9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed previously, the specification is split into multiple definitions and flows, each of which has
its own set of use cases. The core OAuth 2.0 specification has somewhat accurately been described as a security protocol generator, because it can be used
to design the security architecture for many different use cases. As discussed in the previous section, these systems aren’t necessarily compatible with each other."

This is indeed a very good description of the current mess.

10. Section 15.2 is not provided. Its title is : Proof of possession (PoP) tokens. I am really curious to read how you can achieve PoP in the case of an ABC attack.

11. I also observed that there is no chapter dealing with privacy issues. Nowadays, it is an important topic. In particular on how to prevent an authorization server
to act as Big Brother. A section should be added to deal with privacy issues.

12. Finally a typo on page 18: "Since OAuth 2.0 with bearer tokens provides no message signatures, is it not meant to be used outside of HTTPS (HTTP over TLS)".


Denis


+1 to Phil's reference to SCIM, and since it looks like you're looking to do end user authentication you should look at OpenID Connect:

http://openid.net/connect/

There are a lot of ways to get an authentication protocol based on OAuth very, very wrong, and I've covered some of the big ones in an article I wrote (with the community's help) a few years ago:

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

Furthermore, I've covered the topic in my upcoming book, OAuth 2 In Action, which you might find useful:

https://www.manning.com/books/oauth-2-in-action

All said, the space is not as easy as you may think it is at first and there are a lot of pitfalls. But the good news is that you're not the first to dive in here and there are a lot of really good solutions already available.

 -- Justin


On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote:
You are headed down the road to a very big domain called identity management and provisioning. 

You might want to look at SCIM (RFC7643, 7644) for a restful api pattern.

SCIM is usually OAuth enabled but the scopes/rights have not yet been standardized. There is however some obvious access control patterns that apply from the old ldap directory world.  

Phil

On Feb 1, 2017, at 6:36 PM, Yunqi Zhang <zhangyunqi.cs@gmail.com> wrote:

Hi all,

I'm working on a set of API endpoints to allow institutions to manage their users and records, and their users to read their own records.

Specifically, each institution will get a {client_id} and a {secret} after registering with us, which allows them to create users under its institution using [POST https://hostname/users/]. Then the institution can also insert records for each user using [POST https://hostname/users/:user_id/]. Once a user has been created, he/she can read his/her own records using [GET https://hostname/users/:user_id/].

In this process, there are two types of authentications I would like to achieve, which I'm thinking about using oauth. However, I am super new on oauth and have four questions.

Institution authentication (e.g., company FOO will have READ and WRITE access to https://hostname/ to create users under its own institution, insert records for specific users): (1) Since this part of the system will be created and run by the institution, this should be a "client credential grant" using {client_id} and {secret} of the institution, correct?

End-user authentication (e.g., user John Doe of company FOO will have READ access to https://hostname/users/:john_doe_user_id/ to read his own personal records): (2) Because this part of the system will probably run on the web/mobile app created by company FOO, this should be a "resource owner credential grant" using {username}, {password} of the specific user, correct?

(3) Because I am allow two types of different authentications, which will use two types of different {access_token}s I assume, would that be something weird (or hard to build) under the oauth model?

(4) What if the web/mobile app created by a subset of the companies already has its own authentication and does not want to create another password for each of its users, what should I do? For example, company FOO has its own authentication for its web/mobile app and does not want to bother creating another password for each of its user (i.e., requires only {username}), whereas company BAR would like to create another password for each user (i.e., requires {username} and {password}). What kind of authentication model should I use for a scenario like this?

Thank you very much for your help!

Yunqi
_______________________________________________
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


--------------B156F25F7669F4CEF8B24D10-- From nobody Thu Feb 2 15:03:46 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 688FC1299A8; Thu, 2 Feb 2017 15:03:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148607662042.13885.2832003093930390561.idtracker@ietfa.amsl.com> Date: Thu, 02 Feb 2017 15:03:40 -0800 Archived-At: Cc: ietf@ietf.org, draft-ietf-oauth-jwsreq.all@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 23:03:40 -0000 Reviewer: Joel Halpern Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-oauth-jwsreq-?? Reviewer: Joel Halpern Review Date: 2017-02-02 IETF LC End Date: 2017-02-13 IESG Telechat date: 2017-02-16 Summary: This document is ready for publication as a Proposed Standard Major issues: N/A Minor issues: Why is the example if section 4 (and others later on) described as "non-normative"? Is it incomplete? incorrect? An example is, by definition, not a full specification. The language seems designed to reduce the value of the example. I would recommend removing all the "non-normative" notes from the examples. They are clearly stated to be examples. Nits/editorial comments: From nobody Fri Feb 3 02:16:16 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F8B129B8A; Fri, 3 Feb 2017 02:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=GbWDdp5G; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=IZ8PONW+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWD3lU4ulQzi; Fri, 3 Feb 2017 02:16:13 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E146D127078; Fri, 3 Feb 2017 02:16:12 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 5788D20BB0; Fri, 3 Feb 2017 05:16:12 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 03 Feb 2017 05:16:12 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=q0lT6+H+GCSmWsY209ZxQk4Qs+ c=; b=GbWDdp5GhE3GK0/Q7kjFb9zAKsuECnFvb6CPku6EsjXDM6nTMTCuhJJbBE mu1oZKxinAjO9CQqbijpkshB9UrFIaul/1BIuElmXBKvQn5l/j9R09lmGV54xzTH bAy2gZFjKEwNy/n+939OCMqqhgv8M6MF0Hypw+loVUfaNlp/Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=q0 lT6+H+GCSmWsY209ZxQk4Qs+c=; b=IZ8PONW+vEnhVmDDTKuV+FI3sC/nLlM/mU cwQgHk72WRJmfcVXyUs/MdEKpLmH7NsDyUib+BWDiHvFqkm5lZPn8yAc6gu7uEYm zRaIxhrSxceC5j2RIFnIOIr0a6N3q0qNtvCiLmCDbYcNho+DL8u4Z/JAJ12On12t LBCaPlMqs= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 2E3DA6ABFB; Fri, 3 Feb 2017 05:16:12 -0500 (EST) Message-Id: <1486116972.569299.869047696.03427CD3@webmail.messagingengine.com> From: Alexey Melnikov To: Mike Jones , The IESG MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e9b51b02 Date: Fri, 03 Feb 2017 10:16:12 +0000 References: <148602274618.28299.16863291767893795433.idtracker@ietfa.amsl.com> <1486048021.331167.868093568.44D5380B@webmail.messagingengine.com> In-Reply-To: Archived-At: Cc: oauth-chairs@ietf.org, draft-ietf-oauth-amr-values@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 10:16:15 -0000 On Thu, Feb 2, 2017, at 06:05 PM, Mike Jones wrote: > I was planning to stay with the characters specified in 6.1 (a) > https://tools.ietf.org/html/draft-ietf-oauth-amr-values-05#section-6.1: > > a. require that Authentication Method Reference values being > registered use only printable ASCII characters excluding double > quote ('"') and backslash ('\') (the Unicode characters with code > points U+0021, U+0023 through U+005B, and U+005D through U+007E), > > That excludes space. That's the set taken from RFC 7638, Section 6 > https://tools.ietf.org/html/rfc7638#section-6, which is a very related > usage. > > Space is excluded because sometimes in OAuth messages, values are > represented as space-separated strings. I am sorry I misread this earlier: you already exclude space, so the text as specified is fine. > -- Mike > > -----Original Message----- > From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm] > Sent: Thursday, February 2, 2017 7:07 AM > To: Mike Jones ; The IESG > Cc: draft-ietf-oauth-amr-values@ietf.org; Hannes Tschofenig > ; oauth-chairs@ietf.org; oauth@ietf.org > Subject: Re: Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: > (with DISCUSS and COMMENT) > > Hi Mike, > > On Thu, Feb 2, 2017, at 03:05 PM, Mike Jones wrote: > > I'd be OK limiting the protocol elements to using ASCII characters, if > > that would be the IESG's preference. > > I think that would be much simpler for everybody. > > I still want to confirm that spaces are allowed in names. Can you > confirm? > > > > > -----Original Message----- > > From: Alexey Melnikov [mailto:aamelnikov@fastmail.fm] > > Sent: Thursday, February 2, 2017 12:06 AM > > To: The IESG > > Cc: draft-ietf-oauth-amr-values@ietf.org; Hannes Tschofenig > > ; oauth-chairs@ietf.org; > > Hannes.Tschofenig@gmx.net; oauth@ietf.org > > Subject: Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: > > (with DISCUSS and COMMENT) > > > > Alexey Melnikov has entered the following ballot position for > > draft-ietf-oauth-amr-values-05: 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 > > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This is a fine document and I support its publication. However I have > > a small set of issues that I would like to discuss first. > > > > Are non ASCII names needed? (This is a protocol element, not a human > > readable string, so non ASCII is not needed). Are ASCII spaces allowed > > in names? More generally: what do you call printable character? > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > In Section 6.1: suggestion to first describe IANA registration policy, > > then describe restrictions on registered names. Otherwise the current > > text doesn't flow well. > > > > I am also agreeing with Stephen's DISCUSS. > > > > From nobody Fri Feb 3 03:11:05 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A91129588; Fri, 3 Feb 2017 03:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhbqpzHiJtss; Fri, 3 Feb 2017 03:10:57 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 E1B8C129404; Fri, 3 Feb 2017 03:10:56 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id A97A57803D3; Fri, 3 Feb 2017 12:10:54 +0100 (CET) To: ietf@ietf.org, IETF-Announce References: <148581788158.29828.4591033587037530374.idtracker@ietfa.amsl.com> From: Denis Message-ID: <3a6b8cee-ff29-323e-9042-5df6e71a8d81@free.fr> Date: Fri, 3 Feb 2017 12:10:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148581788158.29828.4591033587037530374.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------30BE242EF2C22EC06C360265" Archived-At: Cc: oauth-chairs@ietf.org, oauth@ietf.org, draft-ietf-oauth-jwsreq@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 11:11:00 -0000 This is a multi-part message in MIME format. --------------30BE242EF2C22EC06C360265 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit *Comments on I-D Action: draft-ietf-oauth-jwsreq-11.txt* Two editorial comments first : 1. Guidance is a mass noun, not a count noun, plural doesn't make sense. Please change "guidances" into "guidance" twice in Section 11. 2. In Section 12 : Please remove my name (Denis Pinkas) from this section. Other comments: 3. Section 1.1 (from boiler plate) states: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. There is not a single other occurrence of the word SHALL within this document. In such case, I wonder how this document can be normative. There are however many (useful) "non-normative examples. A non-normative example does not replace requirements. Section 4 states: *A Request Object (Section 2.1) is used to provide authorization* *request parameters for an OAuth 2.0 authorization request.It* *contains OAuth 2.0 [RFC6749] authorization request parameters* *including extension parameters**.* ** RFC 6749 contains 75 pages, but does not contain a single occurrence of the wording "authorization request parameter" nor of "extension parameter". There should be either references to one or more specific sections of this document or, even better, a list of the mandatory/recommended/possible authorization request parameters as well as a list of mandatory/recommended/possible extension parameters should be included in this document. A clear distinction should be made between the parameters used to authenticate the request and the other ones. 4. The introduction states on page 4: (a) (integrity protection) The request can be signed so that the integrity of the request can be checked; This should be changed into: (a) (integrity protection) The request can be authenticated either using a digital signature or using encryption under a secret key so that the integrity of the request can be checked; 5. The introduction states on page 4: (d) (collection minimization) The request can be *signed* by a third party attesting that the authorization request is compliant tocertain policy. The request is not /signed/ by a third party. However, later on, there is the following explanation: In addition, it allows requests to be prepared by a third party so that a client application cannot request more permissions than previously agreed. If it is the intent, the sentence should be rephrased as: (d) (collection minimization) The request can be *verified* by a third party attesting that the authorization request is compliant tocertain policy. 6. Section 10.1. the text states: *When sending the authorization request object through "request"* *parameter, it MUST either be signed using JWS [RFC7515] or encrypted* *using JWE [RFC7516] with then considered appropriate algorithm.* The wording"with then considered appropriate algorithm"is too vague. This should be changed into: *When sending the authorization request object through "request"* *parameter, it MUST either be signed using JWS [RFC7515] or encrypted* *using JWE [RFC7516] using a symmetric key algorithm.* 7. Section 10.2 states: This means that the request object is going to be prepared fresh each time an authorization request is madeand caching cannot be used. What are the implications ? Is it required/recommended to use a nonce ? The text should be made clearer. 8. Section 10.3 states: 10.3.Request Source Authentication The source of the Authorization Request MUST always be verified. There are several ways to do it in this specification. (a)Verifying the JWS Signature of the Request Object. It seems that the case of using a JWE encrypted using a secret key algorithm has been forgotten here. Please add it. 9. Section 10.3 states at its very end: An extension specification should be created as a preventive measure to address potential vulnerabilities that have not yet been identified. Writing a document for vulnerabilities that have not yet been identified is speculative. It would rather be better either to remove this sentence or to explain what is meant by it. 10. Section 11.1 states: *11.1.Collection limitation* ** *When the Client is being granted access to a protected resource* *containing personal data, the Client SHOULD limit the collection of* *personal data to that which is within the bounds of applicable law* *and strictly necessary for the specified purpose(s).*** The /presentation/ of personal data should be limited whether or not the protected resource contains personal data. It is proposed to change this text into: *When the Client requests an access to a protected resource, the Client* *SHOULD limit the presentation of personal data to that which is within * *the bounds of applicable law and strictly necessary for the specified * *purpose(s).*** 11. Section 11.2.1 states: 11.2.1.Request Disclosure This specification allows extension parameters. It would be useful to name either all of them or some of them. RFC 6749 is not crystal clear about this. Denis Pinkas (DP Security Consulting SAS) ============================================================== > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization > Request (JAR)' > 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 2017-02-13. 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 > > > The authorization request in OAuth 2.0 described in RFC 6749 utilizes > query parameter serialization, which means that Authorization Request > parameters are encoded in the URI of the request and sent through > user agents such as web browsers. While it is easy to implement, it > means that (a) the communication through the user agents are not > integrity protected and thus the parameters can be tainted, and (b) > the source of the communication is not authenticated. Because of > these weaknesses, several attacks to the protocol have now been put > forward. > > This document introduces the ability to send request parameters in a > JSON Web Token (JWT) instead, which allows the request to be JWS > signed and/or JWE encrypted so that the integrity, source > authentication and confidentiality property of the Authorization > Request is attained. The request can be sent by value or by > reference. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. > See RFC 3967 for additional information: > rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (Informational - IETF stream) > rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream) > rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream) > Note that some of these references may already be listed in the acceptable Downref Registry. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------30BE242EF2C22EC06C360265 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Comments on I-D Action: draft-ietf-oauth-jwsreq-11.txt

 

Two editorial comments first :

 

1. Guidance is a mass noun, not a count noun, plural doesn't make sense. Please change "guidances" into "guidance" twice in Section 11.

 

2. In Section 12 : Please remove my name (Denis Pinkas) from this section.

 

Other comments:

 

3. Section 1.1 (from boiler plate) states: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

There is not a single other occurrence of the word SHALL within this document. In such case, I wonder how this document can be normative.
There are however many (useful) "non-normative examples. A non-normative example does not replace requirements.

 

Section 4 states:

 

   A Request Object (Section 2.1) is used to provide authorization

   request parameters for an OAuth 2.0 authorization request.  It

   contains OAuth 2.0 [RFC6749] authorization request parameters

   including extension parameters. 

 

RFC 6749 contains 75 pages, but does not contain a single occurrence of the wording "authorization request parameter" nor of "extension parameter".
There should be either references to one or more specific sections of this document or, even better, a list of the mandatory/recommended/possible
authorization request parameters as well as a list of mandatory/recommended/possible extension parameters should be included in this document.


A clear distinction should be made between the parameters used to authenticate the request and the other ones.

 

4. The introduction states on page 4:

 

     (a) (integrity protection) The request can be signed so that the integrity of the request can be checked ;

 

This should be changed into:

 

     (a) (integrity protection) The request can be authenticated either using a digital signature or using encryption under a secret key
          so that the integrity of the request can be checked ;

 

 

5. The introduction states on page 4:

 

(d) (collection minimization) The request can be signed by a third party attesting that the authorization request is compliant to certain policy.

The request is not signed by a third party.


However, later on, there is the following explanation:

 

   In addition, it allows requests to be prepared by a third party so that a client application cannot request
   more permissions than previously agreed. 

 

If it is the intent, the sentence should be rephrased as:

 

(d) (collection minimization) The request can be verified by a third party attesting that the authorization request is compliant to certain policy.

 

 

6. Section 10.1. the text states:

 

   When sending the authorization request object through "request"

   parameter, it MUST either be signed using JWS [RFC7515] or encrypted

   using JWE [RFC7516] with then considered appropriate algorithm.

 

The wording" with then considered appropriate algorithm" is too vague. This should be changed into:

 

   When sending the authorization request object through "request"

   parameter, it MUST either be signed using JWS [RFC7515] or encrypted

   using JWE [RFC7516] using a symmetric key algorithm.

 

 

7. Section 10.2 states:

 

   This means that the request object is going to be prepared fresh each

   time an authorization request is made and caching cannot be used. 

 

What are the implications ? Is it required/recommended to use a nonce ? The text should be made clearer.

 

8. Section 10.3 states:

 

10.3.  Request Source Authentication

 

   The source of the Authorization Request MUST always be verified.

   There are several ways to do it in this specification.

 

   (a)  Verifying the JWS Signature of the Request Object.

 

It seems that the case of using a JWE encrypted using a secret key algorithm has been forgotten here. Please add it.

 

9. Section 10.3 states at its very end:

 

   An extension specification

   should be created as a preventive measure to address potential

   vulnerabilities that have not yet been identified.

 

Writing a document for vulnerabilities that have not yet been identified is speculative. It would rather be better
either to remove this sentence or to explain what is meant by it.

 

10. Section 11.1 states:

 

11.1.  Collection limitation

 

   When the Client is being granted access to a protected resource

   containing personal data, the Client SHOULD limit the collection of

   personal data to that which is within the bounds of applicable law

   and strictly necessary for the specified purpose(s).

 

The presentation of personal data should be limited whether or not the protected resource contains personal data.

 

It is proposed to change this text into:

 

   When the Client requests an access to a protected resource, the Client

   SHOULD limit the presentation of personal data to that which is within

   the bounds of applicable law and strictly necessary for the specified

   purpose(s).

 

11. Section 11.2.1 states:

 

11.2.1.  Request Disclosure

 

   This specification allows extension parameters.

 

It would be useful to name either all of them or some of them. RFC 6749 is not crystal clear about this.

 


Denis Pinkas (DP Security Consulting SAS)

 

============================================================== 




The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization
   Request (JAR)'
  <draft-ietf-oauth-jwsreq-11.txt> 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 2017-02-13. 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


   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be JWS
   signed and/or JWE encrypted so that the integrity, source
   authentication and confidentiality property of the Authorization
   Request is attained.  The request can be sent by value or by
   reference.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (Informational - IETF stream)
    rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream)
    rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream)
Note that some of these references may already be listed in the acceptable Downref Registry.


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


--------------30BE242EF2C22EC06C360265-- From nobody Fri Feb 3 06:54:06 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37144129DBB for ; Fri, 3 Feb 2017 06:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_GJMitf_4sQ for ; Fri, 3 Feb 2017 06:54:02 -0800 (PST) Received: from linzer.ki.iif.hu (linzer.ki.iif.hu [193.224.163.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD2A129DB9 for ; Fri, 3 Feb 2017 06:53:58 -0800 (PST) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by linzer.ki.iif.hu (Postfix) with ESMTP id 6BCE74060C4; Fri, 3 Feb 2017 15:53:56 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from linzer.ki.iif.hu ([IPv6:::ffff:193.224.163.7]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id I1O6vKKN5xAT; Fri, 3 Feb 2017 15:53:55 +0100 (CET) Received: from [IPv6:2001:738:0:401:8476:a736:d2fd:5b66] (unknown [IPv6:2001:738:0:401:8476:a736:d2fd:5b66]) by linzer.ki.iif.hu (Postfix) with ESMTPSA id 362FD4060C2; Fri, 3 Feb 2017 15:53:55 +0100 (CET) To: draft-ietf-oauth-pop-key-distribution@tools.ietf.org, oauth@ietf.org From: =?UTF-8?B?TcOpc3rDoXJvcyBNaWjDoWx5?= Message-ID: <3e63d207-409a-21b7-decd-fcf60f693038@niif.hu> Date: Fri, 3 Feb 2017 15:53:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------9C0E438C963D7244AE8414D1" Archived-At: Subject: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 14:54:04 -0000 This is a multi-part message in MIME format. --------------9C0E438C963D7244AE8414D1 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Hi, Your draft says in https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-4.2 The 'key' parameter either contains a plain JWK structure or a JWK encrypted with a JWE. But not mentioning that plain JWK is base64url encoded. In the same section in the example in Figure2: "key":"eyJhbGciOiJSU0ExXzUi That is == base64 encoded '{"alg":"RSA1_5' So "key" is not a plain JWK JSON, but base64 encoded (plain JWK). So it is confusing for me.. Please confirm that it is missed to state in the draft but you meant that the plain JWK is in base64 encoded format. The 'key' parameter either contains a plain _/bas64url encoded/_ JWK structure or a JWK encrypted with a JWE. Many Thanks, Misi --------------9C0E438C963D7244AE8414D1 Content-Type: text/html; charset=iso-8859-2 Content-Transfer-Encoding: 7bit

Hi,

Your draft says in https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-4.2

	The 'key' parameter either contains a plain JWK structure or a JWK encrypted with a JWE.

But not mentioning that plain JWK is base64url encoded.

In the same section in the example in Figure2:

	 "key":"eyJhbGciOiJSU0ExXzUi

That is == base64 encoded '{"alg":"RSA1_5'

So "key" is not a plain JWK JSON, but base64 encoded (plain JWK).


So it is confusing for me..

Please confirm that it is missed to state in the draft but you meant that the plain JWK is in base64 encoded format.

The 'key' parameter either contains a plain bas64url encoded JWK structure or a JWK encrypted with a JWE.

Many Thanks,
Misi

--------------9C0E438C963D7244AE8414D1-- From nobody Fri Feb 3 06:54:17 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67172129DB8 for ; Fri, 3 Feb 2017 06:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.398 X-Spam-Level: X-Spam-Status: No, score=-7.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7f1C2_GW1SfD for ; Fri, 3 Feb 2017 06:54:04 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 D11E8129DB6 for ; Fri, 3 Feb 2017 06:54:01 -0800 (PST) X-AuditID: 12074423-c07ff70000003ebe-0b-589499869bf1 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 (Symantec Messaging Gateway) with SMTP id 68.5B.16062.68994985; Fri, 3 Feb 2017 09:54:00 -0500 (EST) 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 v13ErwwV007292; Fri, 3 Feb 2017 09:53:58 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v13EruRw015064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 3 Feb 2017 09:53:57 -0500 To: Denis , oauth@ietf.org References: <318C729C-3374-47B9-BF7E-F5F2F81EAC33@oracle.com> <39f411e1-da84-b25c-a894-9e0a629d6d95@mit.edu> <71435970-7138-f739-bb92-1208d44817e1@free.fr> From: Justin Richer Message-ID: <9a2da0db-fa67-3216-c520-0d746d10cfc8@mit.edu> Date: Fri, 3 Feb 2017 09:53:47 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <71435970-7138-f739-bb92-1208d44817e1@free.fr> Content-Type: multipart/alternative; boundary="------------DCB3C727114730E55B14E87C" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hTV1u2YOSXC4PQuLov1XXYWJ9++YnNg 8uhf95nVY8mSn0wBTFFcNimpOZllqUX6dglcGXM29LIVnPjBVPHjyCHGBsaNM5i6GDk5JARM JC61vmEDsYUE2pgk9j4U6mLkArI3MEqsP3OPHcK5xSTxZeoxdpAqYQFTiZUHzzN2MXJwiAjo SVw5ngdR84xR4vW/jcwgNWwCqhLT17SAbeAVsJK4924JM0g9i4CKxM9NwSBhUYEYiZd7VrFA lAhKnJz5BMzmFLCWOPzsMitIObNAmMTHpYkTGPlmIamahZABCTML2ErcmbubGcKWl2jeOhvK 1pVYtG0FO7L4Aka2VYyyKblVurmJmTnFqcm6xcmJeXmpRbpmermZJXqpKaWbGEHBy+6ivIPx ZZ/3IUYBDkYlHt4Cz8kRQqyJZcWVuYcYJTmYlER5m9OmRAjxJeWnVGYkFmfEF5XmpBYfYpTg YFYS4f3WD5TjTUmsrEotyodJSXOwKInzims0RggJpCeWpGanphakFsFkZTg4lCR43WYANQoW paanVqRl5pQgpJk4OEGG8wAN3zodZHhxQWJucWY6RP4Uoy7Hvu1nXjIJseTl56VKifMGggwS ACnKKM2DmwNKOglvD5u+YhQHekuY1xKkigeYsOAmvQJawgS05OfjSSBLShIRUlINjJqrrqb2 rVL2Ywzpi1exmN6ebt0Z7XDioc1Snk8nt/kuVPq4myfYap2k9kdOE1+bE853ZD+tvHve6G6W xO2bku8eM30U27x9E4frXtkLdstbHJjkZzd8vPQx6daSKrYveqfqW5O7mh1n2Zy8bLext+TK xLMFrF+uTzX3XiyxRmfNbt/3b9pcryqxFGckGmoxFxUnAgD449V7FQMAAA== Archived-At: Subject: Re: [OAUTH-WG] OAuth for institutional users X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 14:54:09 -0000 This is a multi-part message in MIME format. --------------DCB3C727114730E55B14E87C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Denis, The book is being published very shortly and the text is completed, so there aren't any more updates to be made to it. Additionally, this isn't really the forum for comments on the book (there's an online form for discussion if you're interested: https://forums.manning.com/forums/oauth-2-in-action), this is a list for discussing and developing OAuth itself. Still, most of your comments are general enough misconceptions of OAuth that they may be of interest to others so I'll answer them on the list here, inline below. On 2/2/2017 5:47 PM, Denis wrote: > > Justin, > > Your are making the promotion of your book (OAuth 2 In Action), soon > to be published. > > I browsed through the 23 pages of Chapter 1 that are provided as a > free download. > > I saw the footnote from Manning Publications Co. which states: > > "/We welcome reader comments about anything in the manuscript/" > > Since Manning Publications Co. asked for it, I hope that you will be > able to take into consideration some of my comments before this book > is published. > > I will only comment on a few sentences. > > 1. Page 1: "The application requests authorization from the owner of > the resource and receivestokens that it can use to access the resource". > > Such a model is rather restrictive and does not cover the general case > where an application is willing to perform an operation on a resource > and where the resource tells to the application which kind of > attributes need to be presented by the application for that specific > operation. > In such a case, the resource owner is not involved in anyway at the > time of the request. If this restriction remains, this should be > clearly stated. > This is the model of OAuth: it's a delegation protocol, delegating from a resource owner to a client. What you're describing is a different protocol where the client and resource negotiate attributes for the client to present to the resource to fulfill its requirements. OAuth specifically abstracts that process using the authorization server, and to great success. > 2. Page 10:" To acquire a token, the client first sends the resource > owner to the authorization server in order to request that the > resource owner authorize this client". > > This sentence is not English. You cannot "send the resource owner to > the authorization server". This sentence should be rephrased. > Yes you can send the resource owner to the authorization server -- generally by redirecting their web browser to a page on the authorization server (the authorization endpoint) for the resource owner to interact with the authorization server. > 3. Page 16: "Even worse, some of the available options in OAuth can be > taken in the wrong context or not enforced properly, leading to > insecure implementations. > These kinds of vulnerabilities are discussed at length in the OAuth > Threat Model Document and the vulnerabilities section of this book > (chapters 7, 8, 9, and 10)." > > Bear in mind that RFC 6819 was issued four years ago (in January > 2013). Collusions between servers was considered, but collusions > between clients was omitted, > typically the ABC attack (Alice and Bob Collusion attack). See: > https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html > > You should add some text in section 7.6 to deal with the ABC attack. > Sharing bearer tokens is a well known attack surface and there's really no way to stop that. Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other. I've read everything you've written about the so-called ABC attack and don't think there's more to say about it, especially in an introductory book. > 4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it’s far > from perfect. We will see its replacement at some point in the future, > as with all things > in technology, but no real contender has yet emerged as of the writing > of this book. > > I can agree with you that "OAuth 2.0is far from perfect". Can a > protocol with so many options be a "good protocol" ? Can > interoperability be achieved ? > I don't think so. You then say: " but no real contender has yet > emerged as of the writing of this book". I would rather suggest that > you delete > " but no real contender has yet emerged as of the writing of this book". > I address the optionality and interoperability issues in that chapter, more in chapter 2, and even more in chapter 6. Yes, it's a good protocol, and I'm sorry you don't like it. When there's a delegation protocol that's similarly used across millions of sites and APIs all over the internet, then we can talk about a real contender for replacement. I look forward to that day, but we're not there yet (and I don't think we're anywhere near there). > 5. Page 17: "OAuth assumes that the resource owner is the one that’s > controlling the client". > > I do hope that it is not the case. The client should only be > controlled by an end-user or by a local application and no one else. > The resource owner *is* the end user. Your "should" is the same as the assumption I'm stating. > > 6. Page 17: " OAuth isn’t defined outside of the HTTP protocol. Since > OAuth 2.0 with bearer tokens provides no message signatures, > is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive > secrets and information are passed over the wire, and > OAuth requires a transport layer mechanism such as TLS to protect > these secrets". > > The HTTPS protocol indeed needs to be used for resource data origin > authentication and confidentiality protection of the data being > exchanged. > However, protecting sensitive secrets and information passed over the > wire using TLS does not prevent in anyway an ABC attack. TLS binding > does not provide either any extra protection in case of an ABC attack. > This should be stated since this is an important issue. I really wonder > if you can still say: " OAuth 2.0 is a good protocol". In any case, > OAuth 2.0 is not a protocol but a framework. > It doesn't prevent people from sharing secrets with each other out of band, as we've just talked about, but it does prevent a whole raft of other non-collusive attacks which are significantly more malicious and problematic. > 7. Page 18: "OAuth doesn’t define a token format". > > How do you want to interoperate if no token format is being defined ? > IETF RFCs on the standards track are primarily intended to be used to > address interoperability. > It all is based on *what* OAuth defines interoperability between. OAuth says how a client talks to an AS and how a client talks to an RS. It says nothing about how an RS and AS get along. Since the token format is opaque to the client, OAuth defines no token format because it didn't need to define one to be interoperable in the way it was intended to be. > 8. Page 18 "In fact, the OAuth protocol explicitly states that the > content of the token is completely opaque to the client application. > > This is even worse. In such a case, the client will be unable to make > sure that what he got in the token is really what he was asking for: > nothing more and nothing less. > This is one of OAuth's best features, as it make things simpler. > 9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed > previously, the specification is split into multiple definitions and > flows, each of which has > its own set of use cases. The core OAuth 2.0 specification has > somewhat accurately been described as a security protocol generator, > because it can be used > to design the security architecture for many different use cases. As > discussed in the previous section, these systems aren’t necessarily > compatible with each other." > > This is indeed a very good description of the current mess. > Yes, and I hope you read the rest of the paragraph that explains the nature of that "mess" and why it's set up the way that it is. There's a reason for it, which is why that section is there in the book. > 10. Section 15.2 is not provided. Its title is : *Proof of possession > (PoP) tokens*. I am really curious to read how you can achieve PoP in > the case of an ABC attack. > That's in chapter 15, which you don't have because you haven't bought the book. :) Same with all of the other forward references throughout that section. And you can still share secrets if they're given to you in the PoP case. Or you can just skip the security layer and share the results of the API calls. There's literally nothing in the world that can prevent that level of collusion -- PoP, token binding, DRM... nothing. > 11. I also observed that there is no chapter dealing with *privacy > issues.* Nowadays, it is an important topic. In particular on how to > prevent an authorization server > to act as *Big Brother*. A section should be added to deal with > privacy issues. > This is a topic that has been covered in great depth on the web, and since this is a technical book we didn't feel the need to get into it. I encourage you to write a treatise yourself, please let us know when you do. > 12. Finally a typo on page 18:"Since OAuth 2.0 with bearer tokens > provides no message signatures, *is it*not meant to be used outside of > HTTPS (HTTP over TLS)". > The preview chapters are not the latest copy of the manuscript text as it's being prepared for final publication, so a lot of typos and format errors have been fixed already. Thanks for the feedback, but as I said above, in the future please don't bring up issues you have with the book on this mailing list. -- Justin > > Denis > > >> +1 to Phil's reference to SCIM, and since it looks like you're >> looking to do end user authentication you should look at OpenID Connect: >> >> http://openid.net/connect/ >> >> There are a lot of ways to get an authentication protocol based on >> OAuth very, very wrong, and I've covered some of the big ones in an >> article I wrote (with the community's help) a few years ago: >> >> http://oauth.net/articles/authentication/ >> >> Furthermore, I've covered the topic in my upcoming book, OAuth 2 In >> Action, which you might find useful: >> >> https://www.manning.com/books/oauth-2-in-action >> >> All said, the space is not as easy as you may think it is at first >> and there are a lot of pitfalls. But the good news is that you're not >> the first to dive in here and there are a lot of really good >> solutions already available. >> >> -- Justin >> >> >> On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote: >>> You are headed down the road to a very big domain called identity >>> management and provisioning. >>> >>> You might want to look at SCIM (RFC7643, 7644) for a restful api >>> pattern. >>> >>> SCIM is usually OAuth enabled but the scopes/rights have not yet >>> been standardized. There is however some obvious access control >>> patterns that apply from the old ldap directory world. >>> >>> Phil >>> >>> On Feb 1, 2017, at 6:36 PM, Yunqi Zhang >> > wrote: >>> >>>> Hi all, >>>> >>>> I'm working on a set of API endpoints to allow institutions to >>>> manage their users and records, and their users to read their own >>>> records. >>>> >>>> Specifically, each institution will get a {client_id} and a >>>> {secret} after registering with us, which allows them to create >>>> users under its institution using [POST https://hostname/users/]. >>>> Then the institution can also insert records for each user using >>>> [POST https://hostname/users/:user_id/]. Once a user has been >>>> created, he/she can read his/her own records using [GET >>>> https://hostname/users/:user_id/]. >>>> >>>> In this process, there are two types of authentications I would >>>> like to achieve, which I'm thinking about using oauth. However, I >>>> am super new on oauth and have four questions. >>>> >>>> Institution authentication (e.g., company FOO will have READ and >>>> WRITE access to https://hostname/ to create users under its own >>>> institution, insert records for specific users): (1) Since this >>>> part of the system will be created and run by the institution, this >>>> should be a "client credential grant" using {client_id} and >>>> {secret} of the institution, correct? >>>> >>>> End-user authentication (e.g., user John Doe of company FOO will >>>> have READ access to https://hostname/users/:john_doe_user_id/ to >>>> read his own personal records): (2) Because this part of the system >>>> will probably run on the web/mobile app created by company FOO, >>>> this should be a "resource owner credential grant" using >>>> {username}, {password} of the specific user, correct? >>>> >>>> (3) Because I am allow two types of different authentications, >>>> which will use two types of different {access_token}s I assume, >>>> would that be something weird (or hard to build) under the oauth model? >>>> >>>> (4) What if the web/mobile app created by a subset of the companies >>>> already has its own authentication and does not want to create >>>> another password for each of its users, what should I do? For >>>> example, company FOO has its own authentication for its web/mobile >>>> app and does not want to bother creating another password for each >>>> of its user (i.e., requires only {username}), whereas company BAR >>>> would like to create another password for each user (i.e., requires >>>> {username} and {password}). What kind of authentication model >>>> should I use for a scenario like this? >>>> >>>> Thank you very much for your help! >>>> >>>> Yunqi >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------DCB3C727114730E55B14E87C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Denis,

The book is being published very shortly and the text is completed, so there aren't any more updates to be made to it. Additionally, this isn't really the forum for comments on the book (there's an online form for discussion if you're interested: https://forums.manning.com/forums/oauth-2-in-action), this is a list for discussing and developing OAuth itself. Still, most of your comments are general enough misconceptions of OAuth that they may be of interest to others so I'll answer them on the list here, inline below.


On 2/2/2017 5:47 PM, Denis wrote:

Justin,

Your are making the promotion of your book (OAuth 2 In Action), soon to be published.

I browsed through the 23 pages of Chapter 1 that are provided as a free download.

I saw the footnote from Manning Publications Co. which states:

"We welcome reader comments about anything in the manuscript"

Since Manning Publications Co. asked for it, I hope that you will be able to take into consideration some of my comments before this book is published.

I will only comment on a few sentences.

1. Page 1: "The application requests authorization from the owner of the resource and receives tokens that it can use to access the resource".

Such a model is rather restrictive and does not cover the general case where an application is willing to perform an operation on a resource
and where the resource tells to the application which kind of attributes need to be presented by the application for that specific operation.
In such a case, the resource owner is not involved in anyway at the time of the request. If this restriction remains, this should be clearly stated.


This is the model of OAuth: it's a delegation protocol, delegating from a resource owner to a client. What you're describing is a different protocol where the client and resource negotiate attributes for the client to present to the resource to fulfill its requirements. OAuth specifically abstracts that process using the authorization server, and to great success.

2. Page 10:" To acquire a token, the client first sends the resource owner to the authorization server in order to request that the resource owner authorize this client".

This sentence is not English. You cannot "send the resource owner to the authorization server". This sentence should be rephrased.


Yes you can send the resource owner to the authorization server -- generally by redirecting their web browser to a page on the authorization server (the authorization endpoint) for the resource owner to interact with the authorization server.

3. Page 16: "Even worse, some of the available options in OAuth can be taken in the wrong context or not enforced properly, leading to insecure implementations.
These kinds of vulnerabilities are discussed at length in the OAuth Threat Model Document and the vulnerabilities section of this book (chapters 7, 8, 9, and 10)."

Bear in mind that RFC 6819 was issued four years ago (in January 2013). Collusions between servers was considered, but collusions between clients was omitted,
typically the ABC attack (Alice and Bob Collusion attack). See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

You should add some text in section 7.6 to deal with the ABC attack.


Sharing bearer tokens is a well known attack surface and there's really no way to stop that. Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other. I've read everything you've written about the so-called ABC attack and don't think there's more to say about it, especially in an introductory book.

4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it’s far from perfect. We will see its replacement at some point in the future, as with all things
in technology, but no real contender has yet emerged as of the writing of this book.

I can agree with you that "OAuth 2.0 is far from perfect". Can a protocol with so many options be a "good protocol" ? Can interoperability be achieved ?
I don't think so. You then say: " but no real contender has yet emerged as of the writing of this book". I would rather suggest that you delete
" but no real contender has yet emerged as of the writing of this book".


I address the optionality and interoperability issues in that chapter, more in chapter 2, and even more in chapter 6. Yes, it's a good protocol, and I'm sorry you don't like it. When there's a delegation protocol that's similarly used across millions of sites and APIs all over the internet, then we can talk about a real contender for replacement. I look forward to that day, but we're not there yet (and I don't think we're anywhere near there).

5. Page 17: "OAuth assumes that the resource owner is the one that’s controlling the client".

I do hope that it is not the case. The client should only be controlled by an end-user or by a local application and no one else.


The resource owner *is* the end user. Your "should" is the same as the assumption I'm stating.


6. Page 17: " OAuth isn’t defined outside of the HTTP protocol. Since OAuth 2.0 with bearer tokens provides no message signatures,
is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive secrets and information are passed over the wire, and
OAuth requires a transport layer mechanism such as TLS to protect these secrets".

The HTTPS protocol indeed needs to be used for resource data origin authentication and confidentiality protection of the data being exchanged.
However, protecting sensitive secrets and information passed over the wire using TLS does not prevent in anyway an ABC attack. TLS binding
does not provide either any extra protection in case of an ABC attack. This should be stated since this is an important issue. I really wonder
if you can still say: " OAuth 2.0 is a good protocol". In any case, OAuth 2.0 is not a protocol but a framework.


It doesn't prevent people from sharing secrets with each other out of band, as we've just talked about, but it does prevent a whole raft of other non-collusive attacks which are significantly more malicious and problematic.

7. Page 18: "OAuth doesn’t define a token format".

How do you want to interoperate if no token format is being defined ? IETF RFCs on the standards track are primarily intended to be used to address interoperability.


It all is based on *what* OAuth defines interoperability between. OAuth says how a client talks to an AS and how a client talks to an RS. It says nothing about how an RS and AS get along. Since the token format is opaque to the client, OAuth defines no token format because it didn't need to define one to be interoperable in the way it was intended to be.

8. Page 18 "In fact, the OAuth protocol explicitly states that the content of the token is completely opaque to the client application.

This is even worse. In such a case, the client will be unable to make sure that what he got in the token is really what he was asking for: nothing more and nothing less.


This is one of OAuth's best features, as it make things simpler.

9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed previously, the specification is split into multiple definitions and flows, each of which has
its own set of use cases. The core OAuth 2.0 specification has somewhat accurately been described as a security protocol generator, because it can be used
to design the security architecture for many different use cases. As discussed in the previous section, these systems aren’t necessarily compatible with each other."

This is indeed a very good description of the current mess.


Yes, and I hope you read the rest of the paragraph that explains the nature of that "mess" and why it's set up the way that it is. There's a reason for it, which is why that section is there in the book.

10. Section 15.2 is not provided. Its title is : Proof of possession (PoP) tokens. I am really curious to read how you can achieve PoP in the case of an ABC attack.


That's in chapter 15, which you don't have because you haven't bought the book. :) Same with all of the other forward references throughout that section.

And you can still share secrets if they're given to you in the PoP case. Or you can just skip the security layer and share the results of the API calls. There's literally nothing in the world that can prevent that level of collusion -- PoP, token binding, DRM... nothing.

11. I also observed that there is no chapter dealing with privacy issues. Nowadays, it is an important topic. In particular on how to prevent an authorization server
to act as Big Brother. A section should be added to deal with privacy issues.


This is a topic that has been covered in great depth on the web, and since this is a technical book we didn't feel the need to get into it. I encourage you to write a treatise yourself, please let us know when you do.

12. Finally a typo on page 18: "Since OAuth 2.0 with bearer tokens provides no message signatures, is it not meant to be used outside of HTTPS (HTTP over TLS)".

The preview chapters are not the latest copy of the manuscript text as it's being prepared for final publication, so a lot of typos and format errors have been fixed already.

Thanks for the feedback, but as I said above, in the future please don't bring up issues you have with the book on this mailing list.

 -- Justin


Denis


+1 to Phil's reference to SCIM, and since it looks like you're looking to do end user authentication you should look at OpenID Connect:

http://openid.net/connect/

There are a lot of ways to get an authentication protocol based on OAuth very, very wrong, and I've covered some of the big ones in an article I wrote (with the community's help) a few years ago:

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

Furthermore, I've covered the topic in my upcoming book, OAuth 2 In Action, which you might find useful:

https://www.manning.com/books/oauth-2-in-action

All said, the space is not as easy as you may think it is at first and there are a lot of pitfalls. But the good news is that you're not the first to dive in here and there are a lot of really good solutions already available.

 -- Justin


On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote:
You are headed down the road to a very big domain called identity management and provisioning. 

You might want to look at SCIM (RFC7643, 7644) for a restful api pattern.

SCIM is usually OAuth enabled but the scopes/rights have not yet been standardized. There is however some obvious access control patterns that apply from the old ldap directory world.  

Phil

On Feb 1, 2017, at 6:36 PM, Yunqi Zhang <zhangyunqi.cs@gmail.com> wrote:

Hi all,

I'm working on a set of API endpoints to allow institutions to manage their users and records, and their users to read their own records.

Specifically, each institution will get a {client_id} and a {secret} after registering with us, which allows them to create users under its institution using [POST https://hostname/users/]. Then the institution can also insert records for each user using [POST https://hostname/users/:user_id/]. Once a user has been created, he/she can read his/her own records using [GET https://hostname/users/:user_id/].

In this process, there are two types of authentications I would like to achieve, which I'm thinking about using oauth. However, I am super new on oauth and have four questions.

Institution authentication (e.g., company FOO will have READ and WRITE access to https://hostname/ to create users under its own institution, insert records for specific users): (1) Since this part of the system will be created and run by the institution, this should be a "client credential grant" using {client_id} and {secret} of the institution, correct?

End-user authentication (e.g., user John Doe of company FOO will have READ access to https://hostname/users/:john_doe_user_id/ to read his own personal records): (2) Because this part of the system will probably run on the web/mobile app created by company FOO, this should be a "resource owner credential grant" using {username}, {password} of the specific user, correct?

(3) Because I am allow two types of different authentications, which will use two types of different {access_token}s I assume, would that be something weird (or hard to build) under the oauth model?

(4) What if the web/mobile app created by a subset of the companies already has its own authentication and does not want to create another password for each of its users, what should I do? For example, company FOO has its own authentication for its web/mobile app and does not want to bother creating another password for each of its user (i.e., requires only {username}), whereas company BAR would like to create another password for each user (i.e., requires {username} and {password}). What kind of authentication model should I use for a scenario like this?

Thank you very much for your help!

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


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




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





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

--------------DCB3C727114730E55B14E87C-- From nobody Fri Feb 3 12:42:05 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9F2129532 for ; Fri, 3 Feb 2017 12:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uRmqSUYiP0J for ; Fri, 3 Feb 2017 12:42:00 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 058FB129474 for ; Fri, 3 Feb 2017 12:42:00 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id b65so47478453wmf.0 for ; Fri, 03 Feb 2017 12:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/HNVHvFe0aOFFh0taHRfXRfCtdSqv2a7cHNxFEIoQA4=; b=PKCPpQTdMso0093ajH2gs93vMoa5ouj/MWbkh5KhxGRDt3qnVJUkrQgwQp8bbE1fMT mbeHSgXUgWRFgkzMMhYVx94S6aWtg3Zju6luNcCnRstyhLJ0AXAphuSDbqrUorNEVLmr SaChvpVRem31zbuliaiaoy/uEH9Wh/PJFov+WaBhGXr2AyDw2Vgk0DS3plIUei5aEuaZ iCg2BK4WGyw58aC8C7hK27uKmcSW3Pic5MYxBut/NQ0JuieEPpwk3b5wJTCFoKNPnNXK 4+y9dtSfXt24pjlLmbkMv2sa3ZH8xnNKQHXNyF4d5SWT6Q56YPQInurw2pR4W/HYLfkV md9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/HNVHvFe0aOFFh0taHRfXRfCtdSqv2a7cHNxFEIoQA4=; b=GP/jmrCThb3bnyS2M7FFNz4M8vgZJir6PhZ1KZhaPpW3g89JM9olDL1Bmw+wuKfNHJ eoWWlGlIO6aUus4EweE9WfsML8TlIiobhUUN4OKc695K+51fvR5TJhTT44lJXYydFtYM vKyJC7cKXOTFQfrtZnfLHtZ+4AfZRrF5zcevUBmR5gt2a9DzhjMXbA9/Tx7KClmH0G42 JWxCmGJhn8q4BG4g3smbVxk0kczCgB3LM5XZeGyjWvMCfdzR+YEaPfAIpgaIpwlTMiNB xOhQdUHrKulgvmWXOIVrq3GAFXjYRvqKQGFTgScyStLIFQ4RQc+OHXLpRYxtdKthe2Qp oBMg== X-Gm-Message-State: AMke39lnje7mhpxEHvUjvsyr6KMAU6qsgtBVEOUuA0/eAVv3Hgm9XGQbldJJQAYgi7fKGEL2gxGYcit8u1b9qQ== X-Received: by 10.28.206.199 with SMTP id e190mr3078513wmg.98.1486154518362; Fri, 03 Feb 2017 12:41:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.154.194 with HTTP; Fri, 3 Feb 2017 12:41:57 -0800 (PST) In-Reply-To: <9a2da0db-fa67-3216-c520-0d746d10cfc8@mit.edu> References: <318C729C-3374-47B9-BF7E-F5F2F81EAC33@oracle.com> <39f411e1-da84-b25c-a894-9e0a629d6d95@mit.edu> <71435970-7138-f739-bb92-1208d44817e1@free.fr> <9a2da0db-fa67-3216-c520-0d746d10cfc8@mit.edu> From: Yunqi Zhang Date: Fri, 3 Feb 2017 15:41:57 -0500 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=94eb2c193efe2600c20547a650d0 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth for institutional users X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 20:42:04 -0000 --94eb2c193efe2600c20547a650d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you very much guys. What is the trade off between using nested resources (e.g., https://hostname/users/:user_id/records/:record_id/) v.s. flattened resources (e.g., https://hostname/users/:user_id/ and https://hostname/records/:record_id/)? Thank you! Yunqi On Fri, Feb 3, 2017 at 9:53 AM, Justin Richer wrote: > Hi Denis, > > The book is being published very shortly and the text is completed, so > there aren't any more updates to be made to it. Additionally, this isn't > really the forum for comments on the book (there's an online form for > discussion if you're interested: https://forums.manning.com/ > forums/oauth-2-in-action), this is a list for discussing and developing > OAuth itself. Still, most of your comments are general enough > misconceptions of OAuth that they may be of interest to others so I'll > answer them on the list here, inline below. > > On 2/2/2017 5:47 PM, Denis wrote: > > Justin, > > Your are making the promotion of your book (OAuth 2 In Action), soon to > be published. > > I browsed through the 23 pages of Chapter 1 that are provided as a free > download. > > I saw the footnote from Manning Publications Co. which states: > > "*We welcome reader comments about anything in the manuscript*" > > Since Manning Publications Co. asked for it, I hope that you will be able > to take into consideration some of my comments before this book is > published. > > I will only comment on a few sentences. > > 1. Page 1: "The application requests authorization from the owner of the > resource and receives tokens that it can use to access the resource". > > Such a model is rather restrictive and does not cover the general case > where an application is willing to perform an operation on a resource > and where the resource tells to the application which kind of attributes > need to be presented by the application for that specific operation. > In such a case, the resource owner is not involved in anyway at the time > of the request. If this restriction remains, this should be clearly state= d. > > > This is the model of OAuth: it's a delegation protocol, delegating from a > resource owner to a client. What you're describing is a different protoco= l > where the client and resource negotiate attributes for the client to > present to the resource to fulfill its requirements. OAuth specifically > abstracts that process using the authorization server, and to great succe= ss. > > 2. Page 10:" To acquire a token, the client first sends the resource owne= r > to the authorization server in order to request that the resource owner > authorize this client". > > This sentence is not English. You cannot "send the resource owner to the > authorization server". This sentence should be rephrased. > > > Yes you can send the resource owner to the authorization server -- > generally by redirecting their web browser to a page on the authorization > server (the authorization endpoint) for the resource owner to interact wi= th > the authorization server. > > 3. Page 16: "Even worse, some of the available options in OAuth can be > taken in the wrong context or not enforced properly, leading to insecure > implementations. > These kinds of vulnerabilities are discussed at length in the OAuth Threa= t > Model Document and the vulnerabilities section of this book (chapters 7, = 8, > 9, and 10)." > > Bear in mind that RFC 6819 was issued four years ago (in January 2013). > Collusions between servers was considered, but collusions between clients > was omitted, > typically the ABC attack (Alice and Bob Collusion attack). See: > https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html > > You should add some text in section 7.6 to deal with the ABC attack. > > > Sharing bearer tokens is a well known attack surface and there's really n= o > way to stop that. Even PoP-style tokens can be shared since nothing stops > Bob and Alice from sharing their secrets with each other. I've read > everything you've written about the so-called ABC attack and don't think > there's more to say about it, especially in an introductory book. > > 4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it=E2=80=99s = far from > perfect. We will see its replacement at some point in the future, as with > all things > in technology, but no real contender has yet emerged as of the writing of > this book. > > I can agree with you that "OAuth 2.0 is far from perfect". Can a protocol > with so many options be a "good protocol" ? Can interoperability be > achieved ? > I don't think so. You then say: " but no real contender has yet emerged a= s > of the writing of this book". I would rather suggest that you delete > " but no real contender has yet emerged as of the writing of this book". > > > I address the optionality and interoperability issues in that chapter, > more in chapter 2, and even more in chapter 6. Yes, it's a good protocol, > and I'm sorry you don't like it. When there's a delegation protocol that'= s > similarly used across millions of sites and APIs all over the internet, > then we can talk about a real contender for replacement. I look forward t= o > that day, but we're not there yet (and I don't think we're anywhere near > there). > > 5. Page 17: "OAuth assumes that the resource owner is the one that=E2=80= =99s > controlling the client". > > I do hope that it is not the case. The client should only be controlled b= y > an end-user or by a local application and no one else. > > > The resource owner *is* the end user. Your "should" is the same as the > assumption I'm stating. > > > 6. Page 17: " OAuth isn=E2=80=99t defined outside of the HTTP protocol. S= ince > OAuth 2.0 with bearer tokens provides no message signatures, > is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive > secrets and information are passed over the wire, and > OAuth requires a transport layer mechanism such as TLS to protect these > secrets". > > The HTTPS protocol indeed needs to be used for resource data origin > authentication and confidentiality protection of the data being exchanged= . > However, protecting sensitive secrets and information passed over the wir= e > using TLS does not prevent in anyway an ABC attack. TLS binding > does not provide either any extra protection in case of an ABC attack. > This should be stated since this is an important issue. I really wonder > if you can still say: " OAuth 2.0 is a good protocol". In any case, OAuth > 2.0 is not a protocol but a framework. > > > It doesn't prevent people from sharing secrets with each other out of > band, as we've just talked about, but it does prevent a whole raft of oth= er > non-collusive attacks which are significantly more malicious and > problematic. > > 7. Page 18: "OAuth doesn=E2=80=99t define a token format". > > How do you want to interoperate if no token format is being defined ? IET= F > RFCs on the standards track are primarily intended to be used to address > interoperability. > > > It all is based on *what* OAuth defines interoperability between. OAuth > says how a client talks to an AS and how a client talks to an RS. It says > nothing about how an RS and AS get along. Since the token format is opaqu= e > to the client, OAuth defines no token format because it didn't need to > define one to be interoperable in the way it was intended to be. > > 8. Page 18 "In fact, the OAuth protocol explicitly states that the conten= t > of the token is completely opaque to the client application. > > This is even worse. In such a case, the client will be unable to make sur= e > that what he got in the token is really what he was asking for: nothing > more and nothing less. > > > This is one of OAuth's best features, as it make things simpler. > > 9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed > previously, the specification is split into multiple definitions and flow= s, > each of which has > its own set of use cases. The core OAuth 2.0 specification has somewhat > accurately been described as a security protocol generator, because it ca= n > be used > to design the security architecture for many different use cases. As > discussed in the previous section, these systems aren=E2=80=99t necessari= ly > compatible with each other." > > This is indeed a very good description of the current mess. > > > Yes, and I hope you read the rest of the paragraph that explains the > nature of that "mess" and why it's set up the way that it is. There's a > reason for it, which is why that section is there in the book. > > 10. Section 15.2 is not provided. Its title is : *Proof of possession > (PoP) tokens*. I am really curious to read how you can achieve PoP in the > case of an ABC attack. > > > That's in chapter 15, which you don't have because you haven't bought the > book. :) Same with all of the other forward references throughout that > section. > > And you can still share secrets if they're given to you in the PoP case. > Or you can just skip the security layer and share the results of the API > calls. There's literally nothing in the world that can prevent that level > of collusion -- PoP, token binding, DRM... nothing. > > 11. I also observed that there is no chapter dealing with *privacy > issues.* Nowadays, it is an important topic. In particular on how to > prevent an authorization server > to act as *Big Brother*. A section should be added to deal with privacy > issues. > > > This is a topic that has been covered in great depth on the web, and sinc= e > this is a technical book we didn't feel the need to get into it. I > encourage you to write a treatise yourself, please let us know when you d= o. > > 12. Finally a typo on page 18: "Since OAuth 2.0 with bearer tokens > provides no message signatures, *is it* not meant to be used outside of > HTTPS (HTTP over TLS)". > > The preview chapters are not the latest copy of the manuscript text as > it's being prepared for final publication, so a lot of typos and format > errors have been fixed already. > > Thanks for the feedback, but as I said above, in the future please don't > bring up issues you have with the book on this mailing list. > > -- Justin > > > > Denis > > +1 to Phil's reference to SCIM, and since it looks like you're looking to > do end user authentication you should look at OpenID Connect: > > http://openid.net/connect/ > > There are a lot of ways to get an authentication protocol based on OAuth > very, very wrong, and I've covered some of the big ones in an article I > wrote (with the community's help) a few years ago: > > http://oauth.net/articles/authentication/ > > Furthermore, I've covered the topic in my upcoming book, OAuth 2 In > Action, which you might find useful: > > https://www.manning.com/books/oauth-2-in-action > > All said, the space is not as easy as you may think it is at first and > there are a lot of pitfalls. But the good news is that you're not the fir= st > to dive in here and there are a lot of really good solutions already > available. > > -- Justin > > On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote: > > You are headed down the road to a very big domain called identity > management and provisioning. > > You might want to look at SCIM (RFC7643, 7644) for a restful api pattern. > > SCIM is usually OAuth enabled but the scopes/rights have not yet been > standardized. There is however some obvious access control patterns that > apply from the old ldap directory world. > > Phil > > On Feb 1, 2017, at 6:36 PM, Yunqi Zhang wrote: > > Hi all, > > I'm working on a set of API endpoints to allow institutions to manage > their users and records, and their users to read their own records. > > Specifically, each institution will get a {client_id} and a {secret} afte= r > registering with us, which allows them to create users under its > institution using [POST https://hostname/users/]. Then the institution > can also insert records for each user using [POST > https://hostname/users/:user_id/]. Once a user has been created, he/she > can read his/her own records using [GET https://hostname/users/:user_id/]= . > > In this process, there are two types of authentications I would like to > achieve, which I'm thinking about using oauth. However, I am super new on > oauth and have four questions. > > Institution authentication (e.g., company FOO will have READ and WRITE > access to https://hostname/ to create users under its own institution, > insert records for specific users): (1) Since this part of the system wil= l > be created and run by the institution, this should be a "client credentia= l > grant" using {client_id} and {secret} of the institution, correct? > > End-user authentication (e.g., user John Doe of company FOO will have REA= D > access to https://hostname/users/:john_doe_user_id/ to read his own > personal records): (2) Because this part of the system will probably run = on > the web/mobile app created by company FOO, this should be a "resource own= er > credential grant" using {username}, {password} of the specific user, > correct? > > (3) Because I am allow two types of different authentications, which will > use two types of different {access_token}s I assume, would that be > something weird (or hard to build) under the oauth model? > > (4) What if the web/mobile app created by a subset of the companies > already has its own authentication and does not want to create another > password for each of its users, what should I do? For example, company FO= O > has its own authentication for its web/mobile app and does not want to > bother creating another password for each of its user (i.e., requires onl= y > {username}), whereas company BAR would like to create another password fo= r > each user (i.e., requires {username} and {password}). What kind of > authentication model should I use for a scenario like this? > > Thank you very much for your help! > > Yunqi > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --94eb2c193efe2600c20547a650d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you very much guys.

What is the t= rade off between using nested resources (e.g., https://hostname/users/:user_id/records= /:record_id/) v.s. flattened resources (e.g., https://hostname/users/:user_id/ and https://hostname/records/:record_id/= )?

Thank you!

Yunqi
=

On Fri, Feb= 3, 2017 at 9:53 AM, Justin Richer <jricher@mit.edu> wrote:
=20 =20 =20

Hi Denis,

The book is being published very shortly and the text is completed, so there aren't any more updates to be made to it. Additionally, this isn't really the forum for comments on the boo= k (there's an online form for discussion if you're interested: https://f= orums.manning.com/forums/oauth-2-in-action), this is a list for discussing and developing OAuth itself. Still, most of your comments are general enough misconceptions of OAuth that they may be of interest to others so I'll answer them on the list here= , inline below.


On 2/2/2017 5:47 PM= , Denis wrote:
=20

Justin,

Your are making the promotion of your book = (OAuth 2 In Action)= , soon to be published.

I browsed through the 23 pages of Chapter 1 that are provided as a free download.

I saw the footnote from Manning Publication= s Co. which states:

"We welcome reader comments about = anything in the manuscript"

Since Manning Publications Co. asked for it= , I hope that you will be able to take into consideration some of my comments before this book is published.

I will only comment on a few sentences.<= /u>

1. Page 1: "The application requests authorization from the owner of the resource and receives tokens that it = can use to access the resource".

Such a model is rather restrictive and does= not cover the general case where an application is willing to perform an operation on a resource
and where the resource tells to the application which kind of attributes need to be presented by the application for that specific operation.
In such a case, the resource owner is not involved in anyway at the time of the request. If this restriction remains, this should be clearly stated.


 This is the model of OAuth: it's a delegation protocol, delegating from a resource owner to a client. What you're describing is a different protocol where the client and resource negotiate attributes for the client to present to the resource to fulfill its requirements. OAuth specifically abstracts that process using the authorization server, and to great success.

2. Page 10:" To acquire a token, the client first sends the resource owner to the authorization server in order to request that the resource owner authorize this client".=

This sentence is not English. You cannot &q= uot;send the resource owner to the authorization server". This sentence should be rephrased.


 Yes you can send the resource owner to the authorization server -- generally by redirecting their web browser to a page on the authorization server (the authorization endpoint) for the resource owner to interact with the authorization server.

3. Page 16: "Even worse, some of the available options in OAu= th can be taken in the wrong context or not enforced properly, leading to insecure implementations.
These kinds of vulnerabilities are discussed at length in the OAuth Threat Model Document and the vulnerabilities section of this book (chapters 7, 8, 9, and 10)."

Bear in mind that RFC 6819 was issued four years ago (in January 2013). Collusions between servers was considered, but collusions between clients was omitted,
typically the ABC attack (Alice and Bob Collusion attack). See: https://www.ietf.org/mail-a= rchive/web/oauth/current/msg16767.html=

You should add some text in section 7.6 to = deal with the ABC attack.


Sharing bearer tokens is a well known attack surface and there's really no way to stop that. Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other. I've read everything you've written about the so-ca= lled ABC attack and don't think there's more to say about it, especi= ally in an introductory book.

4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it=E2=80=99s far from perfect. We will see its replacement at s= ome point in the future, as with all things
in technology, but no real contender has yet emerged as of the writing of this book.

I can agree with you that "OAuth 2.0 is far from perfect". Can a protocol with so many options be a "good protocol" ? = Can interoperability be achieved ?
I don't think so. You then say: " but no real contende= r has yet emerged as of the writing of this book". I would rathe= r suggest that you delete
" but no real contender has yet emerged as of the writing = of this book".


I address the optionality and interoperability issues in that chapter, more in chapter 2, and even more in chapter 6. Yes, it's a good protocol, and I'm sorry you don't like it. When there'= s a delegation protocol that's similarly used across millions of sites and APIs all over the internet, then we can talk about a real contender for replacement. I look forward to that day, but we're no= t there yet (and I don't think we're anywhere near there).

5. Page 17: "OAuth assumes that the resource owner is the one that=E2=80=99s controlling the client".

I do hope that it is not the case. The clie= nt should only be controlled by an end-user or by a local application and no one else.


 The resource owner *is* the end user. Your "should" is the sa= me as the assumption I'm stating.


6. Page 17: " OAuth isn=E2=80=99t defined outside of the HTT= P protocol. Since OAuth 2.0 with bearer tokens provides no message signatures,
is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive secrets and information are passed over the wire, and
OAuth requires a transport layer mechanism such as TLS to protect these secrets".

The HTTPS protocol indeed needs to be used = for resource data origin authentication and confidentiality protection of the data being exchanged.
However, protecting sensitive secrets and information passed over the wire using TLS does not prevent in anyway an ABC attack. TLS binding
does not provide either any extra protection in case of an ABC attack. This should be stated since this is an important issue. I really wonder
if you can still say: " OAuth 2.0 is a good protocol"= . In any case, OAuth 2.0 is not= a protocol but a framework.


 It doesn't prevent people from sharing secrets with each other out of band, as we've just talked about, but it does prevent a whole raft of other non-collusive attacks which are significantly more malicious and problematic.

7. Page 18: "OAuth doesn=E2=80=99t define a token format"= ;.

How do you want to interoperate if no token format is being defined ? IETF RFCs on the standards track are primarily intended to be used to address interoperability.


It all is based on *what* OAuth defines interoperability between. OAuth says how a client talks to an AS and how a client talks to an RS. It says nothing about how an RS and AS get along. Since the token format is opaque to the client, OAuth defines no token format because it didn't need to define one to be interoperable in the way it was intended to be.

8. Page 18 "In fact, the OAuth protocol explicitly states tha= t the content of the token is completely opaque to the client application.

This is even worse. In such a case, the cli= ent will be unable to make sure that what he got in the token is really what he was asking for: nothing more and nothing less.


 This is one of OAuth's best features, as it make things simpler.

9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed previously, the specification is split into multiple definitions and flows, each of which has
its own set of use cases. The core OAuth 2.0 specification has somewhat accurately been described as a security protocol generator, because it can be used
to design the security architecture for many different use cases. As discussed in the previous section, these systems aren=E2=80=99t necessarily compatible with each other."=

This is indeed a very good description of t= he current mess.


Yes, and I hope you read the rest of the paragraph that explains the nature of that "mess" and why it's set up the way that it= is. There's a reason for it, which is why that section is there in the book.

10. Section 15.2 is not provided. Its title= is : Proof of possession (PoP) tokens. I am really curious to read how you can achieve PoP in the case of an ABC attack.


 That's in chapter 15, which you don't have because you haven= 9;t bought the book. :) Same with all of the other forward references throughout that section.

And you can still share secrets if they're given to you in the PoP case. Or you can just skip the security layer and share the results of the API calls. There's literally nothing in the world that can prevent that level of collusion -- PoP, token binding, DRM... nothing.

11. I also observed that there is no chapte= r dealing with privacy issues. Nowadays, it is an important topic. In particular on how to prevent an authorization server
to act as Big Brother. A section should be added to deal with privacy issues.


This is a topic that has been covered in great depth on the web, and since this is a technical book we didn't feel the need to get into it. I encourage you to write a treatise yourself, please let us know when you do.

=20 =20 =20 =20 =20

12. Finally a typo on page 18: "Since OAuth 2.0 with bearer tokens provides no message signatures, is it not mea= nt to be used outside of HTTPS (HTTP over TLS)".

 The preview chapters are not the latest copy of the manuscript text as it's being prepared for final publication, so a lot of typos and format errors have been fixed already.

Thanks for the feedback, but as I said above, in the future please don't bring up issues you have with the book on this mailing list.<= span class=3D"HOEnZb">

=C2=A0-- Justin



Denis

=20 =20 =20 =20 =20

+1 to Phil's reference to SCIM, and since it looks like you're looking to do end user authentication you should look at OpenID Connect:

http://openid.net/connect/

There are a lot of ways to get an authentication protocol based on OAuth very, very wrong, and I've covered some of the big ones in an article I wrote (with the community's help) a few years ago:

http://oauth.n= et/articles/authentication/

Furthermore, I've covered the topic in my upcoming book, OAuth 2 In Action, which you might find useful:

https://= www.manning.com/books/oauth-2-in-action

All said, the space is not as easy as you may think it is at first and there are a lot of pitfalls. But the good news is that you're not the first to dive in here and there are a lot of really good solutions already available.

=C2=A0-- Justin


On 2/2/2017 10:= 52 AM, Phil Hunt (IDM) wrote:
You are headed down the road to a very big domain called identity management and provisioning.=C2=A0

You might wan= t to look at SCIM (RFC7643, 7644) for a restful api pattern.

SCIM is usual= ly OAuth enabled but the scopes/rights have not yet been standardized. There is however some obvious access control patterns that apply from the old ldap directory world. =C2=A0

Phil

On Feb 1, 2017, at 6:36 PM, Yunqi Zhang <zhangyunqi.cs@gmail.com> wrote:

Hi all,

I'm working on a set of API endpoints to allow institutions to manage their users and records, and their users to read their own records.

Specifically, each institution will get a {client_id} and a {secret} after registering with us, which allows them to create users under its institution using [POST https://hostname/users/]. Then the institution can also insert records for each user using [POST https://hostname/users/:user_id/]. Once a user has been created, he/she can read his/her own records using [GET https://hostname/users/:user_id/].

In this process, there are two types of authentications I would like to achieve, which I'm thinking about using oauth. However, I am super new on oauth and have four questions.

Institution authentication (e.g., company FOO will have READ and WRITE access to https://hostname/ to create users under its own institution, insert records for specific users): (1) Since this part of the system will be created and run by the institution, this should be a "client credential grant" usin= g {client_id} and {secret} of the institution, correct?

End-user authentication (e.g., user John Doe of company FOO will have READ access to https://hostname/users/= :john_doe_user_id/ to read his own personal records): (2) Because this part of the system will probably run on the web/mobile app created by company FOO, this should be a "resour= ce owner credential grant" using {username}, {password} of the specific user, correct?

(3) Because I am allow two types of different authentications, which will use two types of different {access_token}s I assume, would that be something weird (or hard to build) under the oauth model?

(4) What if the web/mobile app created by a subset of the companies already has its own authentication and does not want to create another password for each of its users, what should I do? For example, company FOO has its own authentication for its web/mobile app and does not want to bother creating another password for each of its user (i.e., requires only {username}), whereas company BAR would like to create another password for each user (i.e., requires {username} and {password}). What kind of authentication model should I use for a scenario like this?

Thank you very much for your help!

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


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




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





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


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


--94eb2c193efe2600c20547a650d0-- From nobody Fri Feb 3 13:53:49 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66976129999 for ; Fri, 3 Feb 2017 13:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA0JL35APjhh for ; Fri, 3 Feb 2017 13:53:45 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17E8129562 for ; Fri, 3 Feb 2017 13:53:44 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id b65so50030855wmf.0 for ; Fri, 03 Feb 2017 13:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ubgCvLt7LpvLbzMhDvLyIz28RfjLbEGvdxDLTJtAze4=; b=WBd1HZ7aysQ+pjGslcPWT1KMbASYMxIJOh9mDsTuukaM7PWtUruirTHPUbLMII8vu/ fdsAENnOOIITOqsZp+UGuTMYwpfxdUTRcJ22GU4QbC58hCJQqBdzgvXWqukwI2dKRx+j 95lUyLmNsXqbqd7IQ/Za1IAt/JOW8+fOX/wZWsdNwacGhXZ3AuYTCbp002qQXf6Kppnm EBzVQ4ma4HWZ2xi1eoDB7k14T1IvvWLgoO73k/eskVnq2S9lp77fUiuZuWJoTUilPWDq a4tL8EVw7apY6kIK1ZxLuDTAqlKHw+lm71eNJg3Vv1Uau/U5Z8PRg9ZqdILAi6cAqCl4 MBbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ubgCvLt7LpvLbzMhDvLyIz28RfjLbEGvdxDLTJtAze4=; b=a3laOt45xERfFyARPokK8RpC2UVlMpJiviaBlXT3bdSW0rQnt6yhPP0TyrZMcQ3vwB w98Dg48Dgc69fvGg7gyunIF0iUfimZLafAc0ryMmxNzbHPrDo1G2bgYegyP1BUWxZ28X l7/jtvl//UlVTSViadaB6RtuyE5vQmPrRpwYpKOnJH1TR14zdBcWFNyS/F2pDLUW7B7C nhWTWj7rWTZ3gBfeqbsCOdaX4D0DJCArKaB48L5K28HWuIAKrUysrpv+6l5thmIpAt9o KbM/biyKrOYQSTw9PyVq2xoTrEZDZ5MouBy360DrMnlIWea/pNMtFVSxsdW9qtkgi52o 0eqQ== X-Gm-Message-State: AMke39nwabbP/U4g+JAF5n6+ZKFLBqXfM3z/QCzbuSxzkYdATnPCGzoeuvTs6tWLcYOFLI0hrPq8D9K0TE4jFA== X-Received: by 10.28.141.199 with SMTP id p190mr3274268wmd.89.1486158823025; Fri, 03 Feb 2017 13:53:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.154.194 with HTTP; Fri, 3 Feb 2017 13:53:42 -0800 (PST) In-Reply-To: References: <318C729C-3374-47B9-BF7E-F5F2F81EAC33@oracle.com> <39f411e1-da84-b25c-a894-9e0a629d6d95@mit.edu> <71435970-7138-f739-bb92-1208d44817e1@free.fr> <9a2da0db-fa67-3216-c520-0d746d10cfc8@mit.edu> From: Yunqi Zhang Date: Fri, 3 Feb 2017 16:53:42 -0500 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=001a114355a6b9f4490547a7506c Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth for institutional users X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 21:53:48 -0000 --001a114355a6b9f4490547a7506c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In addition, what is the common practice for granting access to nested resources? For example, is it possible to grant read-only access to https://hostname/users/AAAA1234/ to user "AAAA1234" after login, but no access to other users' data like https://hostname/users/BBBB5678/? Thank you very much! Yunqi On Fri, Feb 3, 2017 at 3:41 PM, Yunqi Zhang wrote= : > Thank you very much guys. > > What is the trade off between using nested resources (e.g., > https://hostname/users/:user_id/records/:record_id/) v.s. flattened > resources (e.g., https://hostname/users/:user_id/ and > https://hostname/records/:record_id/)? > > Thank you! > > Yunqi > > On Fri, Feb 3, 2017 at 9:53 AM, Justin Richer wrote: > >> Hi Denis, >> >> The book is being published very shortly and the text is completed, so >> there aren't any more updates to be made to it. Additionally, this isn't >> really the forum for comments on the book (there's an online form for >> discussion if you're interested: https://forums.manning.com/for >> ums/oauth-2-in-action), this is a list for discussing and developing >> OAuth itself. Still, most of your comments are general enough >> misconceptions of OAuth that they may be of interest to others so I'll >> answer them on the list here, inline below. >> >> On 2/2/2017 5:47 PM, Denis wrote: >> >> Justin, >> >> Your are making the promotion of your book (OAuth 2 In Action), soon to >> be published. >> >> I browsed through the 23 pages of Chapter 1 that are provided as a free >> download. >> >> I saw the footnote from Manning Publications Co. which states: >> >> "*We welcome reader comments about anything in the manuscript*" >> >> Since Manning Publications Co. asked for it, I hope that you will be abl= e >> to take into consideration some of my comments before this book is >> published. >> >> I will only comment on a few sentences. >> >> 1. Page 1: "The application requests authorization from the owner of the >> resource and receives tokens that it can use to access the resource". >> >> Such a model is rather restrictive and does not cover the general case >> where an application is willing to perform an operation on a resource >> and where the resource tells to the application which kind of attributes >> need to be presented by the application for that specific operation. >> In such a case, the resource owner is not involved in anyway at the time >> of the request. If this restriction remains, this should be clearly stat= ed. >> >> >> This is the model of OAuth: it's a delegation protocol, delegating from = a >> resource owner to a client. What you're describing is a different protoc= ol >> where the client and resource negotiate attributes for the client to >> present to the resource to fulfill its requirements. OAuth specifically >> abstracts that process using the authorization server, and to great succ= ess. >> >> 2. Page 10:" To acquire a token, the client first sends the resource >> owner to the authorization server in order to request that the resource >> owner authorize this client". >> >> This sentence is not English. You cannot "send the resource owner to the >> authorization server". This sentence should be rephrased. >> >> >> Yes you can send the resource owner to the authorization server -- >> generally by redirecting their web browser to a page on the authorizatio= n >> server (the authorization endpoint) for the resource owner to interact w= ith >> the authorization server. >> >> 3. Page 16: "Even worse, some of the available options in OAuth can be >> taken in the wrong context or not enforced properly, leading to insecure >> implementations. >> These kinds of vulnerabilities are discussed at length in the OAuth >> Threat Model Document and the vulnerabilities section of this book >> (chapters 7, 8, 9, and 10)." >> >> Bear in mind that RFC 6819 was issued four years ago (in January 2013). >> Collusions between servers was considered, but collusions between client= s >> was omitted, >> typically the ABC attack (Alice and Bob Collusion attack). See: >> https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html >> >> You should add some text in section 7.6 to deal with the ABC attack. >> >> >> Sharing bearer tokens is a well known attack surface and there's really >> no way to stop that. Even PoP-style tokens can be shared since nothing >> stops Bob and Alice from sharing their secrets with each other. I've rea= d >> everything you've written about the so-called ABC attack and don't think >> there's more to say about it, especially in an introductory book. >> >> 4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it=E2=80=99s= far from >> perfect. We will see its replacement at some point in the future, as wit= h >> all things >> in technology, but no real contender has yet emerged as of the writing o= f >> this book. >> >> I can agree with you that "OAuth 2.0 is far from perfect". Can a >> protocol with so many options be a "good protocol" ? Can interoperabilit= y >> be achieved ? >> I don't think so. You then say: " but no real contender has yet emerged >> as of the writing of this book". I would rather suggest that you delete >> " but no real contender has yet emerged as of the writing of this book". >> >> >> I address the optionality and interoperability issues in that chapter, >> more in chapter 2, and even more in chapter 6. Yes, it's a good protocol= , >> and I'm sorry you don't like it. When there's a delegation protocol that= 's >> similarly used across millions of sites and APIs all over the internet, >> then we can talk about a real contender for replacement. I look forward = to >> that day, but we're not there yet (and I don't think we're anywhere near >> there). >> >> 5. Page 17: "OAuth assumes that the resource owner is the one that=E2=80= =99s >> controlling the client". >> >> I do hope that it is not the case. The client should only be controlled >> by an end-user or by a local application and no one else. >> >> >> The resource owner *is* the end user. Your "should" is the same as the >> assumption I'm stating. >> >> >> 6. Page 17: " OAuth isn=E2=80=99t defined outside of the HTTP protocol. = Since >> OAuth 2.0 with bearer tokens provides no message signatures, >> is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive >> secrets and information are passed over the wire, and >> OAuth requires a transport layer mechanism such as TLS to protect these >> secrets". >> >> The HTTPS protocol indeed needs to be used for resource data origin >> authentication and confidentiality protection of the data being exchange= d. >> However, protecting sensitive secrets and information passed over the >> wire using TLS does not prevent in anyway an ABC attack. TLS binding >> does not provide either any extra protection in case of an ABC attack. >> This should be stated since this is an important issue. I really wonder >> if you can still say: " OAuth 2.0 is a good protocol". In any case, OAut= h >> 2.0 is not a protocol but a framework. >> >> >> It doesn't prevent people from sharing secrets with each other out of >> band, as we've just talked about, but it does prevent a whole raft of ot= her >> non-collusive attacks which are significantly more malicious and >> problematic. >> >> 7. Page 18: "OAuth doesn=E2=80=99t define a token format". >> >> How do you want to interoperate if no token format is being defined ? >> IETF RFCs on the standards track are primarily intended to be used to >> address interoperability. >> >> >> It all is based on *what* OAuth defines interoperability between. OAuth >> says how a client talks to an AS and how a client talks to an RS. It say= s >> nothing about how an RS and AS get along. Since the token format is opaq= ue >> to the client, OAuth defines no token format because it didn't need to >> define one to be interoperable in the way it was intended to be. >> >> 8. Page 18 "In fact, the OAuth protocol explicitly states that the >> content of the token is completely opaque to the client application. >> >> This is even worse. In such a case, the client will be unable to make >> sure that what he got in the token is really what he was asking for: >> nothing more and nothing less. >> >> >> This is one of OAuth's best features, as it make things simpler. >> >> 9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed >> previously, the specification is split into multiple definitions and flo= ws, >> each of which has >> its own set of use cases. The core OAuth 2.0 specification has somewhat >> accurately been described as a security protocol generator, because it c= an >> be used >> to design the security architecture for many different use cases. As >> discussed in the previous section, these systems aren=E2=80=99t necessar= ily >> compatible with each other." >> >> This is indeed a very good description of the current mess. >> >> >> Yes, and I hope you read the rest of the paragraph that explains the >> nature of that "mess" and why it's set up the way that it is. There's a >> reason for it, which is why that section is there in the book. >> >> 10. Section 15.2 is not provided. Its title is : *Proof of possession >> (PoP) tokens*. I am really curious to read how you can achieve PoP in >> the case of an ABC attack. >> >> >> That's in chapter 15, which you don't have because you haven't bought th= e >> book. :) Same with all of the other forward references throughout that >> section. >> >> And you can still share secrets if they're given to you in the PoP case. >> Or you can just skip the security layer and share the results of the API >> calls. There's literally nothing in the world that can prevent that leve= l >> of collusion -- PoP, token binding, DRM... nothing. >> >> 11. I also observed that there is no chapter dealing with *privacy >> issues.* Nowadays, it is an important topic. In particular on how to >> prevent an authorization server >> to act as *Big Brother*. A section should be added to deal with privacy >> issues. >> >> >> This is a topic that has been covered in great depth on the web, and >> since this is a technical book we didn't feel the need to get into it. I >> encourage you to write a treatise yourself, please let us know when you = do. >> >> 12. Finally a typo on page 18: "Since OAuth 2.0 with bearer tokens >> provides no message signatures, *is it* not meant to be used outside of >> HTTPS (HTTP over TLS)". >> >> The preview chapters are not the latest copy of the manuscript text as >> it's being prepared for final publication, so a lot of typos and format >> errors have been fixed already. >> >> Thanks for the feedback, but as I said above, in the future please don't >> bring up issues you have with the book on this mailing list. >> >> -- Justin >> >> >> >> Denis >> >> +1 to Phil's reference to SCIM, and since it looks like you're looking t= o >> do end user authentication you should look at OpenID Connect: >> >> http://openid.net/connect/ >> >> There are a lot of ways to get an authentication protocol based on OAuth >> very, very wrong, and I've covered some of the big ones in an article I >> wrote (with the community's help) a few years ago: >> >> http://oauth.net/articles/authentication/ >> >> Furthermore, I've covered the topic in my upcoming book, OAuth 2 In >> Action, which you might find useful: >> >> https://www.manning.com/books/oauth-2-in-action >> >> All said, the space is not as easy as you may think it is at first and >> there are a lot of pitfalls. But the good news is that you're not the fi= rst >> to dive in here and there are a lot of really good solutions already >> available. >> >> -- Justin >> >> On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote: >> >> You are headed down the road to a very big domain called identity >> management and provisioning. >> >> You might want to look at SCIM (RFC7643, 7644) for a restful api pattern= . >> >> SCIM is usually OAuth enabled but the scopes/rights have not yet been >> standardized. There is however some obvious access control patterns that >> apply from the old ldap directory world. >> >> Phil >> >> On Feb 1, 2017, at 6:36 PM, Yunqi Zhang wrote: >> >> Hi all, >> >> I'm working on a set of API endpoints to allow institutions to manage >> their users and records, and their users to read their own records. >> >> Specifically, each institution will get a {client_id} and a {secret} >> after registering with us, which allows them to create users under its >> institution using [POST https://hostname/users/]. Then the institution >> can also insert records for each user using [POST >> https://hostname/users/:user_id/]. Once a user has been created, he/she >> can read his/her own records using [GET https://hostname/users/:user_id/ >> ]. >> >> In this process, there are two types of authentications I would like to >> achieve, which I'm thinking about using oauth. However, I am super new o= n >> oauth and have four questions. >> >> Institution authentication (e.g., company FOO will have READ and WRITE >> access to https://hostname/ to create users under its own institution, >> insert records for specific users): (1) Since this part of the system wi= ll >> be created and run by the institution, this should be a "client credenti= al >> grant" using {client_id} and {secret} of the institution, correct? >> >> End-user authentication (e.g., user John Doe of company FOO will have >> READ access to https://hostname/users/:john_doe_user_id/ to read his own >> personal records): (2) Because this part of the system will probably run= on >> the web/mobile app created by company FOO, this should be a "resource ow= ner >> credential grant" using {username}, {password} of the specific user, >> correct? >> >> (3) Because I am allow two types of different authentications, which wil= l >> use two types of different {access_token}s I assume, would that be >> something weird (or hard to build) under the oauth model? >> >> (4) What if the web/mobile app created by a subset of the companies >> already has its own authentication and does not want to create another >> password for each of its users, what should I do? For example, company F= OO >> has its own authentication for its web/mobile app and does not want to >> bother creating another password for each of its user (i.e., requires on= ly >> {username}), whereas company BAR would like to create another password f= or >> each user (i.e., requires {username} and {password}). What kind of >> authentication model should I use for a scenario like this? >> >> Thank you very much for your help! >> >> Yunqi >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > --001a114355a6b9f4490547a7506c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In addition, what is the common practice for granting acce= ss to nested resources? For example, is it possible to grant read-only acce= ss to https://hostname/users/A= AAA1234/ to user "AAAA1234" after login, but no access to oth= er users' data like https:= //hostname/users/BBBB5678/?

Thank you very much!

Yunqi

On Fri, Feb 3, 2017 at 3:41 PM, Yunqi Zhang <z= hangyunqi.cs@gmail.com> wrote:
Thank you very much guys.

What is t= he trade off between using nested resources (e.g., https://hostname/= users/:user_id/records/:record_id/) v.s. flattened resources (e.g.= , https://ho= stname/users/:user_id/ and https://hostname/records/:record_id/)?=

Thank you!

Yunqi

On Fri, Feb 3, 2017 at 9:53 AM, Justin Richer <jricher@mit.edu<= /a>> wrote:
=20 =20 =20

Hi Denis,

The book is being published very shortly and the text is completed, so there aren't any more updates to be made to it. Additionally, this isn't really the forum for comments on the boo= k (there's an online form for discussion if you're interested: https://forums.manning.com/forums/oauth-2-in-action),= this is a list for discussing and developing OAuth itself. Still, most of your comments are general enough misconceptions of OAuth that they may be of interest to others so I'll answer them on the list here= , inline below.


On 2/2/2017 5:47 PM, Denis wrote:
=20

Justin,

Your are making the promotion of your book = (OAuth 2 In Action)= , soon to be published.

I browsed through the 23 pages of Chapter 1 that are provided as a free download.

I saw the footnote from Manning Publication= s Co. which states:

"We welcome reader comments about = anything in the manuscript"

Since Manning Publications Co. asked for it= , I hope that you will be able to take into consideration some of my comments before this book is published.

I will only comment on a few sentences.<= /u>

1. Page 1: "The application requests authorization from the owner of the resource and receives tokens that it = can use to access the resource".

Such a model is rather restrictive and does= not cover the general case where an application is willing to perform an operation on a resource
and where the resource tells to the application which kind of attributes need to be presented by the application for that specific operation.
In such a case, the resource owner is not involved in anyway at the time of the request. If this restriction remains, this should be clearly stated.


 This is the model of OAuth: it's a delegation protocol, delegating from a resource owner to a client. What you're describing is a different protocol where the client and resource negotiate attributes for the client to present to the resource to fulfill its requirements. OAuth specifically abstracts that process using the authorization server, and to great success.

2. Page 10:" To acquire a token, the client first sends the resource owner to the authorization server in order to request that the resource owner authorize this client".=

This sentence is not English. You cannot &q= uot;send the resource owner to the authorization server". This sentence should be rephrased.


 Yes you can send the resource owner to the authorization server -- generally by redirecting their web browser to a page on the authorization server (the authorization endpoint) for the resource owner to interact with the authorization server.

3. Page 16: "Even worse, some of the available options in OAu= th can be taken in the wrong context or not enforced properly, leading to insecure implementations.
These kinds of vulnerabilities are discussed at length in the OAuth Threat Model Document and the vulnerabilities section of this book (chapters 7, 8, 9, and 10)."

Bear in mind that RFC 6819 was issued four years ago (in January 2013). Collusions between servers was considered, but collusions between clients was omitted,
typically the ABC attack (Alice and Bob Collusion attack). See: https://ww= w.ietf.org/mail-archive/web/oauth/current/msg16767.html

You should add some text in section 7.6 to = deal with the ABC attack.


Sharing bearer tokens is a well known attack surface and there's really no way to stop that. Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other. I've read everything you've written about the so-ca= lled ABC attack and don't think there's more to say about it, especi= ally in an introductory book.

4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it=E2=80=99s far from perfect. We will see its replacement at s= ome point in the future, as with all things
in technology, but no real contender has yet emerged as of the writing of this book.

I can agree with you that "OAuth 2.0 is far from perfect". Can a protocol with so many options be a "good protocol" ? = Can interoperability be achieved ?
I don't think so. You then say: " but no real contende= r has yet emerged as of the writing of this book". I would rathe= r suggest that you delete
" but no real contender has yet emerged as of the writing = of this book".


I address the optionality and interoperability issues in that chapter, more in chapter 2, and even more in chapter 6. Yes, it's a good protocol, and I'm sorry you don't like it. When there'= s a delegation protocol that's similarly used across millions of sites and APIs all over the internet, then we can talk about a real contender for replacement. I look forward to that day, but we're no= t there yet (and I don't think we're anywhere near there).<= br>

5. Page 17: "OAuth assumes that the resource owner is the one that=E2=80=99s controlling the client".

I do hope that it is not the case. The clie= nt should only be controlled by an end-user or by a local application and no one else.


 The resource owner *is* the end user. Your "should" is the sa= me as the assumption I'm stating.


6. Page 17: " OAuth isn=E2=80=99t defined outside of the HTT= P protocol. Since OAuth 2.0 with bearer tokens provides no message signatures,
is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive secrets and information are passed over the wire, and
OAuth requires a transport layer mechanism such as TLS to protect these secrets".

The HTTPS protocol indeed needs to be used = for resource data origin authentication and confidentiality protection of the data being exchanged.
However, protecting sensitive secrets and information passed over the wire using TLS does not prevent in anyway an ABC attack. TLS binding
does not provide either any extra protection in case of an ABC attack. This should be stated since this is an important issue. I really wonder
if you can still say: " OAuth 2.0 is a good protocol"= . In any case, OAuth 2.0 is not= a protocol but a framework.


 It doesn't prevent people from sharing secrets with each other out of band, as we've just talked about, but it does prevent a whole raft of other non-collusive attacks which are significantly more malicious and problematic.

7. Page 18: "OAuth doesn=E2=80=99t define a token format"= ;.

How do you want to interoperate if no token format is being defined ? IETF RFCs on the standards track are primarily intended to be used to address interoperability.


It all is based on *what* OAuth defines interoperability between. OAuth says how a client talks to an AS and how a client talks to an RS. It says nothing about how an RS and AS get along. Since the token format is opaque to the client, OAuth defines no token format because it didn't need to define one to be interoperable in the way it was intended to be.

8. Page 18 "In fact, the OAuth protocol explicitly states tha= t the content of the token is completely opaque to the client application.

This is even worse. In such a case, the cli= ent will be unable to make sure that what he got in the token is really what he was asking for: nothing more and nothing less.


 This is one of OAuth's best features, as it make things simpler.

9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed previously, the specification is split into multiple definitions and flows, each of which has
its own set of use cases. The core OAuth 2.0 specification has somewhat accurately been described as a security protocol generator, because it can be used
to design the security architecture for many different use cases. As discussed in the previous section, these systems aren=E2=80=99t necessarily compatible with each other."=

This is indeed a very good description of t= he current mess.


Yes, and I hope you read the rest of the paragraph that explains the nature of that "mess" and why it's set up the way that it= is. There's a reason for it, which is why that section is there in the book.

10. Section 15.2 is not provided. Its title= is : Proof of possession (PoP) tokens. I am really curious to read how you can achieve PoP in the case of an ABC attack.


 That's in chapter 15, which you don't have because you haven= 9;t bought the book. :) Same with all of the other forward references throughout that section.

And you can still share secrets if they're given to you in the PoP case. Or you can just skip the security layer and share the results of the API calls. There's literally nothing in the world that can prevent that level of collusion -- PoP, token binding, DRM... nothing.

11. I also observed that there is no chapte= r dealing with privacy issues. Nowadays, it is an important topic. In particular on how to prevent an authorization server
to act as Big Brother. A section should be added to deal with privacy issues.


This is a topic that has been covered in great depth on the web, and since this is a technical book we didn't feel the need to get into it. I encourage you to write a treatise yourself, please let us know when you do.

=20 =20 =20 =20 =20

12. Finally a typo on page 18: "Since OAuth 2.0 with bearer tokens provides no message signatures, is it not mea= nt to be used outside of HTTPS (HTTP over TLS)".

 The preview chapters are not the latest copy of the manuscript text as it's being prepared for final publication, so a lot of typos and format errors have been fixed already.

Thanks for the feedback, but as I said above, in the future please don't bring up issues you have with the book on this mailing list.<= span class=3D"m_-2923391792041753136HOEnZb">

=C2=A0-- Justin



Denis

=20 =20 =20 =20 =20

+1 to Phil's reference to SCIM, and since it looks like you're looking to do end user authentication you should look at OpenID Connect:

http://= openid.net/connect/

There are a lot of ways to get an authentication protocol based on OAuth very, very wrong, and I've covered some of the big ones in an article I wrote (with the community's help) a few years ago:

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

Furthermore, I've covered the topic in my upcoming book, OAuth 2 In Action, which you might find useful:

https://www.manning.com/books/oauth-2-in-action

All said, the space is not as easy as you may think it is at first and there are a lot of pitfalls. But the good news is that you're not the first to dive in here and there are a lot of really good solutions already available.

=C2=A0-- Justin


On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote:
You are headed down the road to a very big domain called identity management and provisioning.=C2=A0

You might want to look at SCIM (RFC7643, 7644) for a restful api pattern.

SCIM is usually OAuth enabled but the scopes/rights have not yet been standardized. There is however some obvious access control patterns that apply from the old ldap directory world. =C2=A0

Phil

On Feb 1, 2017, at 6:36 PM, Yunqi Zhang <zhangyunqi.cs@gmail.com> wrote:

Hi all,

I'm working on a set of API endpoints to allow institutions to manage their users and records, and their users to read their own records.

Specifically, each institution will get a {client_id} and a {secret} after registering with us, which allows them to create users under its institution using [POST https://hostname/users/]. Then the institution can also insert records for each user using [POST https://hostname/users/:user_id/]. Once a user has been created, he/she can read his/her own records using [GET https://hostname/users/:user_id/].

In this process, there are two types of authentications I would like to achieve, which I'm thinking about using oauth. However, I am super new on oauth and have four questions.

Institution authentication (e.g., company FOO will have READ and WRITE access to https://hostname/ to create users under its own institution, insert records for specific users): (1) Since this part of the system will be created and run by the institution, this should be a "client credential grant" usin= g {client_id} and {secret} of the institution, correct?

End-user authentication (e.g., user John Doe of company FOO will have READ access to https://hostname/users/= :john_doe_user_id/ to read his own personal records): (2) Because this part of the system will probably run on the web/mobile app created by company FOO, this should be a "resour= ce owner credential grant" using {username}, {password} of the specific user, correct?

(3) Because I am allow two types of different authentications, which will use two types of different {access_token}s I assume, would that be something weird (or hard to build) under the oauth model?

(4) What if the web/mobile app created by a subset of the companies already has its own authentication and does not want to create another password for each of its users, what should I do? For example, company FOO has its own authentication for its web/mobile app and does not want to bother creating another password for each of its user (i.e., requires only {username}), whereas company BAR would like to create another password for each user (i.e., requires {username} and {password}). What kind of authentication model should I use for a scenario like this?

Thank you very much for your help!

Yunqi
_______________________________________________=
OAuth mailing list
OAu= th@ietf.org
https://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





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


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



--001a114355a6b9f4490547a7506c-- From nobody Fri Feb 3 15:57:41 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C81129421 for ; Fri, 3 Feb 2017 15:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.877 X-Spam-Level: X-Spam-Status: No, score=-4.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsBUl2EmGyVk for ; Fri, 3 Feb 2017 15:57:39 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 EA52D129416 for ; Fri, 3 Feb 2017 15:57:38 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id x49so60722775qtc.2 for ; Fri, 03 Feb 2017 15:57:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=/knX1bA/VMze9SMblt3ILlgn9emjE5P27LdToKLNCbk=; b=YtVzbsRc6VQfl/Hbp5Sn0YXgRqTzQorkAjMkhlxX0mTKiAl9QMC0JKXxkOptWn29NF u7ae7lUdvUI0tfKkFejg35IlUf2J8lb12OLnG0m/WKr8VgdovxvTABBC50H3ZdNyAp9n m7vyaVWJdvpsBPX1Q1KHKZANJX5dMfgJX+dzaLq7mZTTgCfhvc7KsgHTqdY9zx8MRcVQ m5uxokMe2X7vVseNrOoXt4M+l/n3I1YeiLH3CYUyaIRxE8WxtwnBqHcFfJP36Sowt3hs XkMgiMEZgI6PugxGv/HtcDJvRckf5IFb1E0VfkfU3uwjGWsp3ipHUE7aL8CyW6rX6rKP U5Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=/knX1bA/VMze9SMblt3ILlgn9emjE5P27LdToKLNCbk=; b=NyVjUi+tneDKuGHWjrzwnRgufXMRLTB0K8387FqS/Uvn2pq5kgSv0+hqs5HRZiflbl 2UbRltV2zLycR7BKcsFXuhPg9xQzt2mFWefhr0poOPtJDZ2WhIunnKh+NrSlEI7HFndy vGuKhPP9rbcP35OHYeQW+UUK6DZy73Fu1vZ4IjFdeAXk9+fOR/242jZBctonL6U/EvAU 0UeVByW2ZxWBjpQL3CQ7h+EcqtM5mwmzq10b9Ln97RZ5fJpcxabW5ZFo/wKwAgn1C/JE 8QR7cfurlCut/tiAIcAeKmaGHYbeIqQon59QAvNgWUy6eB0jwTXNBzAMM6abAqtsH55k pmnA== X-Gm-Message-State: AIkVDXJCFBhTVd2uHQa9PVtTFmhaYh/+9ieLQp0//zx9b8Ey8WxKLvwDbi/IF+BD+wt6Nr6BUmB374rcVmCE2AlM X-Received: by 10.237.37.58 with SMTP id v55mr16297212qtc.15.1486166257676; Fri, 03 Feb 2017 15:57:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.16.207 with HTTP; Fri, 3 Feb 2017 15:57:17 -0800 (PST) In-Reply-To: References: <541A5105-B963-4FA4-94E4-D794A73B3358@ve7jtb.com> From: William Denniss Date: Fri, 3 Feb 2017 15:57:17 -0800 Message-ID: Cc: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a113f42e6de12370547a90bb3 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 23:57:40 -0000 --001a113f42e6de12370547a90bb3 Content-Type: text/plain; charset=UTF-8 I support the adoption of this document as a working group item. On Thu, Feb 2, 2017 at 2:30 PM, Jim Willeke wrote: > +! > I agree this is needed. > > -- > -jim > Jim Willeke > > On Thu, Feb 2, 2017 at 4:33 PM, John Bradley wrote: > >> I am in favour of adoption. >> > On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig < >> hannes.tschofenig@gmx.net> wrote: >> > >> > Hi all, >> > >> > this is the call for adoption of the 'OAuth Security Topics' document >> > following the positive call for adoption at the last IETF >> > meeting in Seoul. >> > >> > Here is the document: >> > https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 >> > >> > The intention with this document is to have a place to collect >> > discussions and conclusions around OAuth 2.0 security and to reference >> > the actual solution specifications. >> > >> > Please let us know by Feb 16th whether you accept / object to the >> > adoption of this document as a starting point for work in the OAuth >> > working group. >> > >> > Ciao >> > Hannes & Derek >> > >> > _______________________________________________ >> > 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 > > --001a113f42e6de12370547a90bb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support the adoption of this document as a working group= item.

On Th= u, Feb 2, 2017 at 2:30 PM, Jim Willeke <jim@willeke.com> wrote= :
+!=C2=A0
I agree t= his is needed.

--
-jim
Jim Willeke

On Thu, Feb 2, 2017 at 4:33 PM, John Bradley= <ve7jtb@ve7jtb.com> wrote:
> On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net= > wrote:
>
> Hi all,
>
> this is the call for adoption of the 'OAuth Security Topics' d= ocument
> following the positive call for adoption at the last IETF
> meeting in Seoul.
>
> Here is the document:
> https://tools.ietf.org/ht= ml/draft-lodderstedt-oauth-security-topics-00
>
> The intention with this document is to have a place to collect
> discussions and conclusions around OAuth 2.0 security and to reference=
> the actual solution specifications.
>
> Please let us know by Feb 16th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth > working group.
>
> Ciao
> Hannes & Derek
>
> ______________________________________________= _
> 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


--001a113f42e6de12370547a90bb3-- From nobody Fri Feb 3 16:08:07 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25048129443 for ; Fri, 3 Feb 2017 16:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_aN6clKL9CO for ; Fri, 3 Feb 2017 16:08:04 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F1A129416 for ; Fri, 3 Feb 2017 16:08:04 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id e4so9214739pfg.1 for ; Fri, 03 Feb 2017 16:08:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=fWGn8+ty1NerXTkiIwX5BwjWYA1QYGsl2PvN5epWOpg=; b=PQ2oWJWvlYYijP1MLM5pEDIRxLIZ2GMewJD6fvbrwfgs5r2z3eHR7vv9jpGr5YvJ1x wqn57gjoDVZwwnW6TjwodaQEKZ2ed5V5IKUCwbGweXeZ+FgdAowT0Ma+ZEtTo64qkiFb 04SQIr4IZ5yus9cV91WdTetguwU4tCuTkh+EUSNA/21tDf3uz+nhx5vbq8ZTdorAjEmn CXVDDSYTwscbPcV01y235oJfSC/DX5yjBCUtK03SGbIBEcn/GQ2uvEqpPha4lFSWj+yx Ys9GNk82m/yMcho3GqDf9Y1OA6TIDZNp2Y7Ua3tW/FN/vgbiCY+YAlc/IuSO8qMJRXKq kgew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=fWGn8+ty1NerXTkiIwX5BwjWYA1QYGsl2PvN5epWOpg=; b=BiDTxgF2koRA1bl9d1rQPxT1Dsi0ssyl7iEeF6jfAPP1RjzLFa34Q3KKuIwW1vPHZW XZjVLiZ+w45xKeAKdG1oh02DBXngKZXNe55+mJss/ayxJlVzdFhk3+7gQ8bXsxMkiiIz Yvj2FZCTT/vubz8iyXR+MMtb6GCHYOkvNas9GUCWtTYRWuWnHKaYrz8s72i/XUE5pOhn BlHhJFwEnrJnziJVYCfJUUUh1NKWJ0uX0htTyBmKFN5ddb6cudiA+EKywAB4Pri1OODt slX+RnWOxLxaK1/9SX9DhC4rqfxYQE3p74bwwjFEoRv2uLNpERqoIv/RBdw17r+9wLwP BMbA== X-Gm-Message-State: AIkVDXKmHkRdMOlfFfJL9ZbtLOJ0Lli6t5+gx7Oy89VGOMOxABTblX+ifXV3tc4XOEGF6yQR X-Received: by 10.84.132.1 with SMTP id 1mr24844668ple.44.1486166883588; Fri, 03 Feb 2017 16:08:03 -0800 (PST) Received: from heembo.local ([2605:e000:112b:c167:7c7f:eb6b:c497:85d3]) by smtp.googlemail.com with ESMTPSA id p26sm70319092pgn.39.2017.02.03.16.08.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 16:08:03 -0800 (PST) To: William Denniss References: <541A5105-B963-4FA4-94E4-D794A73B3358@ve7jtb.com> From: Jim Manico Message-ID: <14c5b7d3-9faa-0e2f-1411-689ab13d4fad@manicode.com> Date: Fri, 3 Feb 2017 14:08:01 -1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------744F9936F24D942EC6E4E099" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 00:08:06 -0000 This is a multi-part message in MIME format. --------------744F9936F24D942EC6E4E099 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit I'm just some random idiot am an not in this working group but the work from https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 is one of the most up to date and useful OAuth security resources every published. I am thrilled to see more work put into it. Aloha, Jim On 2/3/17 1:57 PM, William Denniss wrote: > I support the adoption of this document as a working group item. > > On Thu, Feb 2, 2017 at 2:30 PM, Jim Willeke > wrote: > > +! > I agree this is needed. > > -- > -jim > Jim Willeke > > On Thu, Feb 2, 2017 at 4:33 PM, John Bradley > wrote: > > I am in favour of adoption. > > On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig > > > wrote: > > > > Hi all, > > > > this is the call for adoption of the 'OAuth Security Topics' > document > > following the positive call for adoption at the last IETF > > meeting in Seoul. > > > > Here is the document: > > > https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 > > > > > The intention with this document is to have a place to collect > > discussions and conclusions around OAuth 2.0 security and to > reference > > the actual solution specifications. > > > > Please let us know by Feb 16th whether you accept / object > to the > > adoption of this document as a starting point for work in > the OAuth > > working group. > > > > Ciao > > Hannes & Derek > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Jim Manico Manicode Security https://www.manicode.com --------------744F9936F24D942EC6E4E099 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I'm just some random idiot am an not in this working group but the work from https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 is one of the most up to date and useful OAuth security resources every published. I am thrilled to see more work put into it.

Aloha, Jim


On 2/3/17 1:57 PM, William Denniss wrote:
I support the adoption of this document as a working group item.

On Thu, Feb 2, 2017 at 2:30 PM, Jim Willeke <jim@willeke.com> wrote:
+! 
I agree this is needed.

--
-jim
Jim Willeke

On Thu, Feb 2, 2017 at 4:33 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I am in favour of adoption.
> On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
> Hi all,
>
> this is the call for adoption of the 'OAuth Security Topics' document
> following the positive call for adoption at the last IETF
> meeting in Seoul.
>
> Here is the document:
> https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00
>
> The intention with this document is to have a place to collect
> discussions and conclusions around OAuth 2.0 security and to reference
> the actual solution specifications.
>
> Please let us know by Feb 16th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Derek
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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



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




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


-- 
Jim Manico
Manicode Security
https://www.manicode.com
--------------744F9936F24D942EC6E4E099-- From nobody Mon Feb 6 02:56:50 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E3A12951B for ; Mon, 6 Feb 2017 02:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUvG9evzrBVv for ; Mon, 6 Feb 2017 02:56:46 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 AB4531294C2 for ; Mon, 6 Feb 2017 02:56:45 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id C30687803FB; Mon, 6 Feb 2017 11:56:41 +0100 (CET) To: Justin Richer , oauth@ietf.org References: <318C729C-3374-47B9-BF7E-F5F2F81EAC33@oracle.com> <39f411e1-da84-b25c-a894-9e0a629d6d95@mit.edu> <71435970-7138-f739-bb92-1208d44817e1@free.fr> <9a2da0db-fa67-3216-c520-0d746d10cfc8@mit.edu> From: Denis Message-ID: <102c0d64-fdf9-912f-1a6f-abded739779b@free.fr> Date: Mon, 6 Feb 2017 11:56:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <9a2da0db-fa67-3216-c520-0d746d10cfc8@mit.edu> Content-Type: multipart/alternative; boundary="------------2F211D44EEAEBAD2FFB6EB1E" Archived-At: Subject: [OAUTH-WG] Is OAuth 2.0 a delegation protocol or a Big Brother protocol ? (was OAuth for institutional users) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 10:56:49 -0000 This is a multi-part message in MIME format. --------------2F211D44EEAEBAD2FFB6EB1E Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Justin, First of all, thank you for your detailed responses. Since you said: "don't bring up issues you have with the book", let us forget about the book ... but not about the topics that have been raised. You said: " This is the model of OAuth: it's a delegation protocol, delegating from a resource owner to a client. (...) OAuth specifically abstracts that process using the authorization server," I also took a look at: http://nordicapis.com/api-security-oauth-openid-connect-depth/ That text states: (...) After all this, your head may be spinning. Mine was when I first learned these things. It’s normally. To help you you orient yourself, I want to stress one really important high-level point: ·*OAuth is not used for authorization*. You might think it is from it’s name, but it’s not. ·*OAuth is also not for authentication*. If you use it for this, expect a breach if your data is of any value. ·*OAuth is also not for federation*. So what is it for? *It’s for delegation, and delegation**only!** * I also read the following sentences on the web: "Using OAuth as an authentication method is /not recommended/, it is explicitly designed as a delegated authorisation method". "OpenID Connect is just an authentication layer built on top of OAuth2". My head is also spinning ... The real world situation is different. For example, draft-ietf-oauth-token-exchange-07 defines a protocol extending OAuth 2.0 that enables clients to request and obtain security tokens from authorization servers acting in the role of an STS. In such a context, this has nothing to do with a delegation protocol. Nevertheless, let us make the assumption, for the moment, that OAuth 2.0 is "/*for delegation, and delegation*//**/*/only/"*. About privacy, you said: " This is a topic that has been covered in great depth on the web", I can say that privacy considerations _have not been adequately covered_ in the current RFCs or in the IETF drafts from the OAuth WG. When a delegation protocol is needed, the best way to prevent an Authorization Server to act as *Big Brother* is simply to get rid of it, i.e. DON'T use /any/ authorization server, ... since *authorization servers are not needed in the context of a delegation protocol*. Let me explain (without writing a treatise as you suggested) how to design a delegation protocol taking care of privacy principles. In order to be more illustrative, I will reuse the example from your book (since it is a good example): "In the printing example, let’s say you’ve uploaded your vacation photos to the photo-storage site, and now you want to have them printed. The storage site’s API is the resource, and the printing service is the client of that API. You, as the resource owner, need to be able to delegate part of your authority to the printer so that it can read your photos. You probably don’t want the printer to be able to read all of your photos, nor do you want the printer to be able to delete photos or upload new ones of its own. Ultimately, what you’re interested in is getting certain photos printed (...)" I first connect and authenticate to the photo-storage site. Since I am only interested in getting certain photos printed, I then create a temporary context where I select different vacations photos from my vacations in Louisiana last May and from my vacations in Patagonia last December which are placed in different directories. I specify the operation(s) that will be allowed for this context. In this specific case, it will be "read-only". I ask the photo-storage site to generate for me an access token tied to this context that it will be able to recognize itself during the next 24 hours. The PoP (Proof of Possession) of that access token will be demonstrated by anyone able to perform an "adequate" computation using a key referenced in the access token. So, in addition of the access token, I receive either a secret key or a private key corresponding to the referenced key. I then connect and authenticate to the printing service and I transmit to it: * the access token which contains in particular the reference of the context created by the photo-storage site, and * the associated secret key or a private key that it shall use to demonstrate the PoP of the access token. The printing service is thus able to use that information to get an access to the set of photos I have selected on the photo-storage site (and only that set). The printing service will also indicate to me the amount of money that is requested to perform the operation and if, I accept it, I will obtain later on my vacation photos. BTW, when reading the various specifications from the OAuth WG, I have not seen how it is possible to restrict the read-only access to only 20 of my vacations photos that have been placed in different directories. In the solution explained above, the restriction does not need to be indicated in an access token. The approach I suggest is an access control system where the photo-storage site recognizes "delegation tokens" that it has itself generated. These /delegation tokens/ may either be sealed using a symmetric key (which is faster) or signed using an asymmetric key (which is slower). *W*hen OAuth 2.0 is used */for delegation,/**the Authorization Server is indeed able to act as Big Brother**, since it is able to identify the *printing service(s) and the photo-storage site(s) I am using and to trace my activities. It can use that information for itself or, even worse, sell that information to someone else. Obviously, when no Third Party *Authorization Server is being involved in the process, this is impossible.* * * *A privacy issue still remains: the *photo-storage site is able to identify the printing service I am using. If I only want to print 20 vacations photos, there is a better alternative: get back in a package the 20 vacations photos and send that package myself to the printing service of my choice. And in such a case, there is/*no need for any delegation protocol anymore*/ ... Obviously, when the quantity of data to be transferred is rather large, a delegation protocol should be considered, but the user should be made aware of the privacy issues. This is not the case at present. OAuth 2.0 and its derivatives are currently presented as the most up-to-date solution where all the security problems are solved or mitigated one way or another. Unfortunately, this is not the case. So let me say once again: privacy considerations in OAuth 2.0 _have not been sufficiently covered_ in the current RFCs, nor in the IETF drafts from the OAuth WG. OAuth 2.0 should have been designed using Privacy by Design (PbD) principles. The OASIS Privacy Management Reference Model Version 1.0 see http://docs.oasis-open.org/pmrm/PMRM/v1.0/cs01/PMRM-v1.0-cs01.pdf describes an interesting methodology to be followed to implement "Privacy by Design". Even if some steps would need to be improved, it is a good document to start with. Rather than simply adding a privacy considerations section at the end of an IETF draft (which is nice anyway), it would be advantageous to identify at the very beginning of each draft: (a) the model, (b) the exchange flows, (3) the privacy principles that apply to the model and (4) the security requirements that apply to the model. Let us now forget about delegation protocols. An Authorization Server is very useful in a "different protocol where the client and resource negotiate attributes for the client to present to the resource to fulfill its requirements". For example, draft-ietf-oauth-token-exchange-07 defines a protocol extending OAuth 2.0 that enables clients to request and obtain security tokens from authorization servers acting in the role of an STS. My conclusion is the following: -OAuth 2.0, /when used as a delegation protocol/, allows Authorization Servers to act as Big Brother and there is not a single warning about this issue in the published or current documents, -there exists at least one contender to the OAuth 2.0 delegation protocol (sketched above) able to fulfill many (but not all) Privacy by Design (PbD) principles. Denis > Hi Denis, > > The book is being published very shortly and the text is completed, so > there aren't any more updates to be made to it. Additionally, this > isn't really the forum for comments on the book (there's an online > form for discussion if you're interested: > https://forums.manning.com/forums/oauth-2-in-action), this is a list > for discussing and developing OAuth itself. Still, most of your > comments are general enough misconceptions of OAuth that they may be > of interest to others so I'll answer them on the list here, inline below. > > > On 2/2/2017 5:47 PM, Denis wrote: >> >> Justin, >> >> Your are making the promotion of your book (OAuth 2 In Action), soon >> to be published. >> >> I browsed through the 23 pages of Chapter 1 that are provided as a >> free download. >> >> I saw the footnote from Manning Publications Co. which states: >> >> "/We welcome reader comments about anything in the manuscript/" >> >> Since Manning Publications Co. asked for it, I hope that you will be >> able to take into consideration some of my comments before this book >> is published. >> >> I will only comment on a few sentences. >> >> 1. Page 1: "The application requests authorization from the owner of >> the resource and receivestokens that it can use to access the resource". >> >> Such a model is rather restrictive and does not cover the general >> case where an application is willing to perform an operation on a >> resource >> and where the resource tells to the application which kind of >> attributes need to be presented by the application for that specific >> operation. >> In such a case, the resource owner is not involved in anyway at the >> time of the request. If this restriction remains, this should be >> clearly stated. >> > > This is the model of OAuth: it's a delegation protocol, delegating > from a resource owner to a client. What you're describing is a > different protocol where the client and resource negotiate attributes > for the client to present to the resource to fulfill its requirements. > OAuth specifically abstracts that process using the authorization > server, and to great success. > >> 2. Page 10:" To acquire a token, the client first sends the resource >> owner to the authorization server in order to request that the >> resource owner authorize this client". >> >> This sentence is not English. You cannot "send the resource owner to >> the authorization server". This sentence should be rephrased. >> > > Yes you can send the resource owner to the authorization server -- > generally by redirecting their web browser to a page on the > authorization server (the authorization endpoint) for the resource > owner to interact with the authorization server. > >> 3. Page 16: "Even worse, some of the available options in OAuth can >> be taken in the wrong context or not enforced properly, leading to >> insecure implementations. >> These kinds of vulnerabilities are discussed at length in the OAuth >> Threat Model Document and the vulnerabilities section of this book >> (chapters 7, 8, 9, and 10)." >> >> Bear in mind that RFC 6819 was issued four years ago (in January >> 2013). Collusions between servers was considered, but collusions >> between clients was omitted, >> typically the ABC attack (Alice and Bob Collusion attack). See: >> https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html >> >> You should add some text in section 7.6 to deal with the ABC attack. >> > > Sharing bearer tokens is a well known attack surface and there's > really no way to stop that. Even PoP-style tokens can be shared since > nothing stops Bob and Alice from sharing their secrets with each > other. I've read everything you've written about the so-called ABC > attack and don't think there's more to say about it, especially in an > introductory book. > >> 4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it’s far >> from perfect. We will see its replacement at some point in the >> future, as with all things >> in technology, but no real contender has yet emerged as of the >> writing of this book. >> >> I can agree with you that "OAuth 2.0is far from perfect". Can a >> protocol with so many options be a "good protocol" ? Can >> interoperability be achieved ? >> I don't think so. You then say: " but no real contender has yet >> emerged as of the writing of this book". I would rather suggest that >> you delete >> " but no real contender has yet emerged as of the writing of this book". >> > > I address the optionality and interoperability issues in that chapter, > more in chapter 2, and even more in chapter 6. Yes, it's a good > protocol, and I'm sorry you don't like it. When there's a delegation > protocol that's similarly used across millions of sites and APIs all > over the internet, then we can talk about a real contender for > replacement. I look forward to that day, but we're not there yet (and > I don't think we're anywhere near there). > >> 5. Page 17: "OAuth assumes that the resource owner is the one that’s >> controlling the client". >> >> I do hope that it is not the case. The client should only be >> controlled by an end-user or by a local application and no one else. >> > > The resource owner *is* the end user. Your "should" is the same as the > assumption I'm stating. > >> >> 6. Page 17: " OAuth isn’t defined outside of the HTTP protocol. Since >> OAuth 2.0 with bearer tokens provides no message signatures, >> is it not meant to be used outside of HTTPS (HTTP over TLS). >> Sensitive secrets and information are passed over the wire, and >> OAuth requires a transport layer mechanism such as TLS to protect >> these secrets". >> >> The HTTPS protocol indeed needs to be used for resource data origin >> authentication and confidentiality protection of the data being >> exchanged. >> However, protecting sensitive secrets and information passed over the >> wire using TLS does not prevent in anyway an ABC attack. TLS binding >> does not provide either any extra protection in case of an ABC >> attack. This should be stated since this is an important issue. I >> really wonder >> if you can still say: " OAuth 2.0 is a good protocol". In any case, >> OAuth 2.0 is not a protocol but a framework. >> > > It doesn't prevent people from sharing secrets with each other out of > band, as we've just talked about, but it does prevent a whole raft of > other non-collusive attacks which are significantly more malicious and > problematic. > >> 7. Page 18: "OAuth doesn’t define a token format". >> >> How do you want to interoperate if no token format is being defined ? >> IETF RFCs on the standards track are primarily intended to be used to >> address interoperability. >> > > It all is based on *what* OAuth defines interoperability between. > OAuth says how a client talks to an AS and how a client talks to an > RS. It says nothing about how an RS and AS get along. Since the token > format is opaque to the client, OAuth defines no token format because > it didn't need to define one to be interoperable in the way it was > intended to be. > >> 8. Page 18 "In fact, the OAuth protocol explicitly states that the >> content of the token is completely opaque to the client application. >> >> This is even worse. In such a case, the client will be unable to make >> sure that what he got in the token is really what he was asking for: >> nothing more and nothing less. >> > > This is one of OAuth's best features, as it make things simpler. > >> 9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed >> previously, the specification is split into multiple definitions and >> flows, each of which has >> its own set of use cases. The core OAuth 2.0 specification has >> somewhat accurately been described as a security protocol generator, >> because it can be used >> to design the security architecture for many different use cases. As >> discussed in the previous section, these systems aren’t necessarily >> compatible with each other." >> >> This is indeed a very good description of the current mess. >> > > Yes, and I hope you read the rest of the paragraph that explains the > nature of that "mess" and why it's set up the way that it is. There's > a reason for it, which is why that section is there in the book. > >> 10. Section 15.2 is not provided. Its title is : *Proof of possession >> (PoP) tokens*. I am really curious to read how you can achieve PoP in >> the case of an ABC attack. >> > > That's in chapter 15, which you don't have because you haven't bought > the book. :) Same with all of the other forward references throughout > that section. > > And you can still share secrets if they're given to you in the PoP > case. Or you can just skip the security layer and share the results of > the API calls. There's literally nothing in the world that can prevent > that level of collusion -- PoP, token binding, DRM... nothing. > >> 11. I also observed that there is no chapter dealing with *privacy >> issues.* Nowadays, it is an important topic. In particular on how to >> prevent an authorization server >> to act as *Big Brother*. A section should be added to deal with >> privacy issues. >> > > This is a topic that has been covered in great depth on the web, and > since this is a technical book we didn't feel the need to get into it. > I encourage you to write a treatise yourself, please let us know when > you do. > >> 12. Finally a typo on page 18:"Since OAuth 2.0 with bearer tokens >> provides no message signatures, *is it*not meant to be used outside >> of HTTPS (HTTP over TLS)". >> > The preview chapters are not the latest copy of the manuscript text as > it's being prepared for final publication, so a lot of typos and > format errors have been fixed already. > > Thanks for the feedback, but as I said above, in the future please > don't bring up issues you have with the book on this mailing list. > > -- Justin > >> >> Denis >> >> >>> +1 to Phil's reference to SCIM, and since it looks like you're >>> looking to do end user authentication you should look at OpenID Connect: >>> >>> http://openid.net/connect/ >>> >>> There are a lot of ways to get an authentication protocol based on >>> OAuth very, very wrong, and I've covered some of the big ones in an >>> article I wrote (with the community's help) a few years ago: >>> >>> http://oauth.net/articles/authentication/ >>> >>> Furthermore, I've covered the topic in my upcoming book, OAuth 2 In >>> Action, which you might find useful: >>> >>> https://www.manning.com/books/oauth-2-in-action >>> >>> All said, the space is not as easy as you may think it is at first >>> and there are a lot of pitfalls. But the good news is that you're >>> not the first to dive in here and there are a lot of really good >>> solutions already available. >>> >>> -- Justin >>> >>> >>> On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote: >>>> You are headed down the road to a very big domain called identity >>>> management and provisioning. >>>> >>>> You might want to look at SCIM (RFC7643, 7644) for a restful api >>>> pattern. >>>> >>>> SCIM is usually OAuth enabled but the scopes/rights have not yet >>>> been standardized. There is however some obvious access control >>>> patterns that apply from the old ldap directory world. >>>> >>>> Phil >>>> >>>> On Feb 1, 2017, at 6:36 PM, Yunqi Zhang >>> > wrote: >>>> >>>>> Hi all, >>>>> >>>>> I'm working on a set of API endpoints to allow institutions to >>>>> manage their users and records, and their users to read their own >>>>> records. >>>>> >>>>> Specifically, each institution will get a {client_id} and a >>>>> {secret} after registering with us, which allows them to create >>>>> users under its institution using [POST https://hostname/users/]. >>>>> Then the institution can also insert records for each user using >>>>> [POST https://hostname/users/:user_id/]. Once a user has been >>>>> created, he/she can read his/her own records using [GET >>>>> https://hostname/users/:user_id/]. >>>>> >>>>> In this process, there are two types of authentications I would >>>>> like to achieve, which I'm thinking about using oauth. However, I >>>>> am super new on oauth and have four questions. >>>>> >>>>> Institution authentication (e.g., company FOO will have READ and >>>>> WRITE access to https://hostname/ to create users under its own >>>>> institution, insert records for specific users): (1) Since this >>>>> part of the system will be created and run by the institution, >>>>> this should be a "client credential grant" using {client_id} and >>>>> {secret} of the institution, correct? >>>>> >>>>> End-user authentication (e.g., user John Doe of company FOO will >>>>> have READ access to https://hostname/users/:john_doe_user_id/ to >>>>> read his own personal records): (2) Because this part of the >>>>> system will probably run on the web/mobile app created by company >>>>> FOO, this should be a "resource owner credential grant" using >>>>> {username}, {password} of the specific user, correct? >>>>> >>>>> (3) Because I am allow two types of different authentications, >>>>> which will use two types of different {access_token}s I assume, >>>>> would that be something weird (or hard to build) under the oauth >>>>> model? >>>>> >>>>> (4) What if the web/mobile app created by a subset of the >>>>> companies already has its own authentication and does not want to >>>>> create another password for each of its users, what should I do? >>>>> For example, company FOO has its own authentication for its >>>>> web/mobile app and does not want to bother creating another >>>>> password for each of its user (i.e., requires only {username}), >>>>> whereas company BAR would like to create another password for each >>>>> user (i.e., requires {username} and {password}). What kind of >>>>> authentication model should I use for a scenario like this? >>>>> >>>>> Thank you very much for your help! >>>>> >>>>> Yunqi >>>>> ___ --------------2F211D44EEAEBAD2FFB6EB1E Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Justin,

First of all, thank you for your detailed responses.

Since you said: "don't bring up issues you have with the book", let us forget about the book ... but not about the topics that have been raised.

You said: " This is the model of OAuth: it's a delegation protocol, delegating from a resource owner to a client. (...) OAuth specifically abstracts
that process using the authorization server,"

I also took a look at: http://nordicapis.com/api-security-oauth-openid-connect-depth/

That text states:

(...)

After all this, your head may be spinning. Mine was when I first learned these things. It’s normally.
To help you you orient yourself, I want to stress one really important high-level point:

·         OAuth is not used for authorization. You might think it is from it’s name, but it’s not.

·         OAuth is also not for authentication. If you use it for this, expect a breach if your data is of any value.

·         OAuth is also not for federation.

So what is it for?

It’s for delegation, and delegation only!

I also read the following sentences on the web:

"Using OAuth as an authentication method is not recommended, it is explicitly designed as a delegated authorisation method".

"OpenID Connect is just an authentication layer built on top of OAuth2".


My head is also spinning ...


The real world situation is different. For example, draft-ietf-oauth-token-exchange-07 defines a protocol extending OAuth 2.0
that enables clients to request and obtain security tokens from authorization servers acting in the role of an STS. In such a context,
this has nothing to do with a delegation protocol.

Nevertheless, let us make the assumption, for the moment, that OAuth 2.0 is "for delegation, and delegation only".

About privacy, you said: " This is a topic that has been covered in great depth on the web",

I can say that privacy considerations have not been adequately covered in the current RFCs or in the IETF drafts from the OAuth WG.

When a delegation protocol is needed, the best way to prevent an Authorization Server to act as Big Brother is simply to get rid of it,
i.e. DON'T use any authorization server, ... since authorization servers are not needed in the context of a delegation protocol.

Let me explain (without writing a treatise as you suggested) how to design a delegation protocol taking care of privacy principles.

In order to be more illustrative, I will reuse the example from your book (since it is a good example):

"In the printing example, let’s say you’ve uploaded your vacation photos to the photo-storage site, and now you want to have them printed.
The storage site’s API is the resource, and the printing service is the client of that API. You, as the resource owner, need to be able to
delegate part of your authority to the printer so that it can read your photos. You probably don’t want the printer to be able to read
all of your photos, nor do you want the printer to be able to delete photos or upload new ones of its own. Ultimately, what you’re interested in
is getting certain photos printed (...)"

I first connect and authenticate to the photo-storage site.

Since I am only interested in getting certain photos printed, I then create a temporary context where I select different vacations photos from my vacations
in Louisiana last May and from my vacations in Patagonia last December which are placed in different directories. I specify the operation(s) that will be
allowed for this context. In this specific case, it will be "read-only".

I ask the photo-storage site to generate for me an access token tied to this context that it will be able to recognize itself during the next 24 hours.
The PoP (Proof of Possession) of that access token will be demonstrated by anyone able to perform an "adequate" computation using a key referenced
in the access token. So, in addition of the access token, I receive either a secret key or a private key corresponding to the referenced key.

I then connect and authenticate to the printing service and I transmit to it:

  • the access token which contains in particular the reference of the context created by the photo-storage site, and
  • the associated secret key or a private key that it shall use to demonstrate the PoP of the access token.

The printing service is thus able to use that information to get an access to the set of photos I have selected on the photo-storage site (and only that set).

The printing service will also indicate to me the amount of money that is requested to perform the operation and if, I accept it, I will obtain later on my vacation photos.

BTW, when reading the various specifications from the OAuth WG, I have not seen how it is possible to restrict the read-only access to only 20 of my vacations
photos that have been placed in different directories. In the solution explained above, the restriction does not need to be indicated in an access token.


The approach I suggest is an access control system where the photo-storage site recognizes "delegation tokens" that it has itself generated.
These delegation tokens may either be sealed using a symmetric key (which is faster) or signed using an asymmetric key (which is slower).

When OAuth 2.0 is used for delegation, the Authorization Server is indeed able to act as Big Brother, since it is able to identify the printing service(s)
and the photo-storage site(s) I am using and to trace my activities. It can use that information for itself or, even worse, sell that information to someone else.

Obviously, when no Third Party Authorization Server is being involved in the process, this is impossible.


A privacy issue still remains: the photo-storage site is able to identify the printing service I am using. If I only want to print 20 vacations photos,
there is a better alternative: get back in a package the 20 vacations photos and send that package myself to the printing service of my choice.
And in such a case, there is no need for any delegation protocol anymore ...

Obviously, when the quantity of data to be transferred is rather large, a delegation protocol should be considered, but the user should be made aware
of the privacy issues. This is not the case at present.

OAuth 2.0 and its derivatives are currently presented as the most up-to-date solution where all the security problems are solved or mitigated one way
or another. Unfortunately, this is not the case.

So let me say once again: privacy considerations in OAuth 2.0 have not been sufficiently covered in the current RFCs, nor in the IETF drafts from the OAuth WG.

OAuth 2.0 should have been designed using Privacy by Design (PbD) principles.

The OASIS Privacy Management Reference Model Version 1.0 see http://docs.oasis-open.org/pmrm/PMRM/v1.0/cs01/PMRM-v1.0-cs01.pdf describes
an interesting methodology to be followed to implement "Privacy by Design". Even if some steps would need to be improved, it is a good document to start with.

Rather than simply adding a privacy considerations section at the end of an IETF draft (which is nice anyway), it would be advantageous to identify
at the very beginning of each draft: (a) the model, (b) the exchange flows, (3) the privacy principles that apply to the model and (4) the security requirements
that apply to the model.


Let us now forget about delegation protocols.

An Authorization Server is very useful in a "different protocol where the client and resource negotiate attributes for the client to present to the resource
to fulfill its requirements".

For example, draft-ietf-oauth-token-exchange-07 defines a protocol extending OAuth 2.0 that enables clients to request and obtain security tokens
from authorization servers acting in the role of an STS.

My conclusion is the following:

-         OAuth 2.0, when used as a delegation protocol, allows Authorization Servers to act as Big Brother and there is not a single warning about this issue
in the published or current documents,

-         there exists at least one contender to the OAuth 2.0 delegation protocol (sketched above) able to fulfill many (but not all) Privacy by Design (PbD) principles.


Denis

Hi Denis,

The book is being published very shortly and the text is completed, so there aren't any more updates to be made to it. Additionally, this isn't really the forum for comments on the book (there's an online form for discussion if you're interested: https://forums.manning.com/forums/oauth-2-in-action), this is a list for discussing and developing OAuth itself. Still, most of your comments are general enough misconceptions of OAuth that they may be of interest to others so I'll answer them on the list here, inline below.


On 2/2/2017 5:47 PM, Denis wrote:

Justin,

Your are making the promotion of your book (OAuth 2 In Action), soon to be published.

I browsed through the 23 pages of Chapter 1 that are provided as a free download.

I saw the footnote from Manning Publications Co. which states:

"We welcome reader comments about anything in the manuscript"

Since Manning Publications Co. asked for it, I hope that you will be able to take into consideration some of my comments before this book is published.

I will only comment on a few sentences.

1. Page 1: "The application requests authorization from the owner of the resource and receives tokens that it can use to access the resource".

Such a model is rather restrictive and does not cover the general case where an application is willing to perform an operation on a resource
and where the resource tells to the application which kind of attributes need to be presented by the application for that specific operation.
In such a case, the resource owner is not involved in anyway at the time of the request. If this restriction remains, this should be clearly stated.


This is the model of OAuth: it's a delegation protocol, delegating from a resource owner to a client. What you're describing is a different protocol where the client and resource negotiate attributes for the client to present to the resource to fulfill its requirements. OAuth specifically abstracts that process using the authorization server, and to great success.

2. Page 10:" To acquire a token, the client first sends the resource owner to the authorization server in order to request that the resource owner authorize this client".

This sentence is not English. You cannot "send the resource owner to the authorization server". This sentence should be rephrased.


Yes you can send the resource owner to the authorization server -- generally by redirecting their web browser to a page on the authorization server (the authorization endpoint) for the resource owner to interact with the authorization server.

3. Page 16: "Even worse, some of the available options in OAuth can be taken in the wrong context or not enforced properly, leading to insecure implementations.
These kinds of vulnerabilities are discussed at length in the OAuth Threat Model Document and the vulnerabilities section of this book (chapters 7, 8, 9, and 10)."

Bear in mind that RFC 6819 was issued four years ago (in January 2013). Collusions between servers was considered, but collusions between clients was omitted,
typically the ABC attack (Alice and Bob Collusion attack). See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

You should add some text in section 7.6 to deal with the ABC attack.


Sharing bearer tokens is a well known attack surface and there's really no way to stop that. Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other. I've read everything you've written about the so-called ABC attack and don't think there's more to say about it, especially in an introductory book.

4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it’s far from perfect. We will see its replacement at some point in the future, as with all things
in technology, but no real contender has yet emerged as of the writing of this book.

I can agree with you that "OAuth 2.0 is far from perfect". Can a protocol with so many options be a "good protocol" ? Can interoperability be achieved ?
I don't think so. You then say: " but no real contender has yet emerged as of the writing of this book". I would rather suggest that you delete
" but no real contender has yet emerged as of the writing of this book".


I address the optionality and interoperability issues in that chapter, more in chapter 2, and even more in chapter 6. Yes, it's a good protocol, and I'm sorry you don't like it. When there's a delegation protocol that's similarly used across millions of sites and APIs all over the internet, then we can talk about a real contender for replacement. I look forward to that day, but we're not there yet (and I don't think we're anywhere near there).

5. Page 17: "OAuth assumes that the resource owner is the one that’s controlling the client".

I do hope that it is not the case. The client should only be controlled by an end-user or by a local application and no one else.


The resource owner *is* the end user. Your "should" is the same as the assumption I'm stating.


6. Page 17: " OAuth isn’t defined outside of the HTTP protocol. Since OAuth 2.0 with bearer tokens provides no message signatures,
is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive secrets and information are passed over the wire, and
OAuth requires a transport layer mechanism such as TLS to protect these secrets".

The HTTPS protocol indeed needs to be used for resource data origin authentication and confidentiality protection of the data being exchanged.
However, protecting sensitive secrets and information passed over the wire using TLS does not prevent in anyway an ABC attack. TLS binding
does not provide either any extra protection in case of an ABC attack. This should be stated since this is an important issue. I really wonder
if you can still say: " OAuth 2.0 is a good protocol". In any case, OAuth 2.0 is not a protocol but a framework.


It doesn't prevent people from sharing secrets with each other out of band, as we've just talked about, but it does prevent a whole raft of other non-collusive attacks which are significantly more malicious and problematic.

7. Page 18: "OAuth doesn’t define a token format".

How do you want to interoperate if no token format is being defined ? IETF RFCs on the standards track are primarily intended to be used to address interoperability.


It all is based on *what* OAuth defines interoperability between. OAuth says how a client talks to an AS and how a client talks to an RS. It says nothing about how an RS and AS get along. Since the token format is opaque to the client, OAuth defines no token format because it didn't need to define one to be interoperable in the way it was intended to be.

8. Page 18 "In fact, the OAuth protocol explicitly states that the content of the token is completely opaque to the client application.

This is even worse. In such a case, the client will be unable to make sure that what he got in the token is really what he was asking for: nothing more and nothing less.


This is one of OAuth's best features, as it make things simpler.

9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed previously, the specification is split into multiple definitions and flows, each of which has
its own set of use cases. The core OAuth 2.0 specification has somewhat accurately been described as a security protocol generator, because it can be used
to design the security architecture for many different use cases. As discussed in the previous section, these systems aren’t necessarily compatible with each other."

This is indeed a very good description of the current mess.


Yes, and I hope you read the rest of the paragraph that explains the nature of that "mess" and why it's set up the way that it is. There's a reason for it, which is why that section is there in the book.

10. Section 15.2 is not provided. Its title is : Proof of possession (PoP) tokens. I am really curious to read how you can achieve PoP in the case of an ABC attack.


That's in chapter 15, which you don't have because you haven't bought the book. :) Same with all of the other forward references throughout that section.

And you can still share secrets if they're given to you in the PoP case. Or you can just skip the security layer and share the results of the API calls. There's literally nothing in the world that can prevent that level of collusion -- PoP, token binding, DRM... nothing.

11. I also observed that there is no chapter dealing with privacy issues. Nowadays, it is an important topic. In particular on how to prevent an authorization server
to act as Big Brother. A section should be added to deal with privacy issues.


This is a topic that has been covered in great depth on the web, and since this is a technical book we didn't feel the need to get into it. I encourage you to write a treatise yourself, please let us know when you do.

12. Finally a typo on page 18: "Since OAuth 2.0 with bearer tokens provides no message signatures, is it not meant to be used outside of HTTPS (HTTP over TLS)".

The preview chapters are not the latest copy of the manuscript text as it's being prepared for final publication, so a lot of typos and format errors have been fixed already.

Thanks for the feedback, but as I said above, in the future please don't bring up issues you have with the book on this mailing list.

 -- Justin


Denis


+1 to Phil's reference to SCIM, and since it looks like you're looking to do end user authentication you should look at OpenID Connect:

http://openid.net/connect/

There are a lot of ways to get an authentication protocol based on OAuth very, very wrong, and I've covered some of the big ones in an article I wrote (with the community's help) a few years ago:

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

Furthermore, I've covered the topic in my upcoming book, OAuth 2 In Action, which you might find useful:

https://www.manning.com/books/oauth-2-in-action

All said, the space is not as easy as you may think it is at first and there are a lot of pitfalls. But the good news is that you're not the first to dive in here and there are a lot of really good solutions already available.

 -- Justin


On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote:
You are headed down the road to a very big domain called identity management and provisioning. 

You might want to look at SCIM (RFC7643, 7644) for a restful api pattern.

SCIM is usually OAuth enabled but the scopes/rights have not yet been standardized. There is however some obvious access control patterns that apply from the old ldap directory world.  

Phil

On Feb 1, 2017, at 6:36 PM, Yunqi Zhang <zhangyunqi.cs@gmail.com> wrote:

Hi all,

I'm working on a set of API endpoints to allow institutions to manage their users and records, and their users to read their own records.

Specifically, each institution will get a {client_id} and a {secret} after registering with us, which allows them to create users under its institution using [POST https://hostname/users/]. Then the institution can also insert records for each user using [POST https://hostname/users/:user_id/]. Once a user has been created, he/she can read his/her own records using [GET https://hostname/users/:user_id/].

In this process, there are two types of authentications I would like to achieve, which I'm thinking about using oauth. However, I am super new on oauth and have four questions.

Institution authentication (e.g., company FOO will have READ and WRITE access to https://hostname/ to create users under its own institution, insert records for specific users): (1) Since this part of the system will be created and run by the institution, this should be a "client credential grant" using {client_id} and {secret} of the institution, correct?

End-user authentication (e.g., user John Doe of company FOO will have READ access to https://hostname/users/:john_doe_user_id/ to read his own personal records): (2) Because this part of the system will probably run on the web/mobile app created by company FOO, this should be a "resource owner credential grant" using {username}, {password} of the specific user, correct?

(3) Because I am allow two types of different authentications, which will use two types of different {access_token}s I assume, would that be something weird (or hard to build) under the oauth model?

(4) What if the web/mobile app created by a subset of the companies already has its own authentication and does not want to create another password for each of its users, what should I do? For example, company FOO has its own authentication for its web/mobile app and does not want to bother creating another password for each of its user (i.e., requires only {username}), whereas company BAR would like to create another password for each user (i.e., requires {username} and {password}). What kind of authentication model should I use for a scenario like this?

Thank you very much for your help!

Yunqi
___

--------------2F211D44EEAEBAD2FFB6EB1E-- From nobody Mon Feb 6 03:02:07 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2027129537; Mon, 6 Feb 2017 03:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyqnBoP-f1FU; Mon, 6 Feb 2017 03:02:04 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 3B18D12950D; Mon, 6 Feb 2017 03:02:04 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 6C92A78048B; Mon, 6 Feb 2017 12:02:00 +0100 (CET) To: Justin Richer , oauth@ietf.org, IETF Tokbind WG References: <318C729C-3374-47B9-BF7E-F5F2F81EAC33@oracle.com> <39f411e1-da84-b25c-a894-9e0a629d6d95@mit.edu> <71435970-7138-f739-bb92-1208d44817e1@free.fr> <9a2da0db-fa67-3216-c520-0d746d10cfc8@mit.edu> From: Denis Message-ID: Date: Mon, 6 Feb 2017 12:02:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <9a2da0db-fa67-3216-c520-0d746d10cfc8@mit.edu> Content-Type: multipart/alternative; boundary="------------310C5A4D40FAE297B2BB215D" Archived-At: Subject: [OAUTH-WG] Is it possible to stop sharing bearer tokens ? (was OAuth for institutional users) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 11:02:07 -0000 This is a multi-part message in MIME format. --------------310C5A4D40FAE297B2BB215D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Justin, You said : "Sharing bearer tokens is a well known attack surface and *there's really no way to stop that*. Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other". You also said: "There's literally *nothing in the world that can prevent that level of collusion* -- PoP, token binding, DRM... nothing". Whatever kind of cryptography is being used, there is indeed are no way to stop sharing bearer tokens using implementations that rely on/_software-only implementations_/. Since the current documents being progressed in the Tokbind WG are based on the use of software only (i.e. TLS binding), none of them is able to prevent that level of collusion. _Note_: I also send a copy of the email to the Tokbind WG (unbearable@ietf.org) so that it can be aware of that discussion. However, when/_using secure hardware_ in a right way, *it is possible to stop sharing bearer tokens*/. Idemix from IBM has been extended to take advantage of the use of smart cards. See the IRMA project (I Reveal My Attributes) at: https://www.irmacard.org/irma/ It is mentioned in particular that "/The security of IRMA depends on the protection of each User’s private key/". Bob cannot indeed transmit any private key to Alice, however he is able to *use* private keys present in his smart card. If Bob accepts to collaborate with Alice, a smart card simply protecting private keys does not possess sufficient properties to counter the ABC attack (Alice and Bob Collusion attack). Bob can perform all the computations that Alice needs, even if Bob and Alice are located in different continents. Hence the IRMA project, based on Idemix, is vulnerable to the ABC attack. Another solution from Microsoft (U-Prove) has the same problem, even when smart cards (or secure elements) are being used: U-prove is also vulnerable to the ABC attack. draft-ietf-oauth-pop-architecture-08 (OAuth 2.0 Proof-of-Possession (PoP) Security Architecture), has expired on January 9, 2017. Since it was only relying on software, it was unable to counter the ABC attack. The *only way* to stop sharing bearer tokens is to use implementations that rely on//some piece of hardware that has /_additional properties_/ beyond the protection of private keys. A secure solution certainly needs to rely on the use of software, but also on the use of secure elements that have specific /_functional and security properties_/. Stopping the sharing of bearer tokens, is not a concern in the case of a delegation protocol, since the use of *Authorization Servers should be deprecated in this context for privacy reasons (as explained in my previous email sent to the OAuth mailing list).* However, stopping the sharing of bearer tokens is mandatory in a "different protocol where the client and resource negotiate attributes for the client to present to the resource to fulfill its requirements". A protocol able to stop sharing bearer tokens needs to transmit data generated by the secure elements (called APDUs - Application Protocol Data Units) so that some APDUscan be directly verified by Authorization Servers and some other APDUscan be directly verified by Resource Servers. In order to stop the sharing of bearer tokens, it is also necessary to specify the format of the access tokens. I noticed that OAuth does not specify the access token itself, since the format is opaque to the protocol flow. As long as this postulate will remain, OAuth and its derivatives won't be able to stop the sharing of bearer tokens. As a conclusion, keeping all the postulates of OAuth 2.0 /unchanged//, /I do agree with you that//"*there's really no way to stop that"*. However, *there's a way to stop that*, but some of the postulates of OAuth 2.0 would need to be changed and some /_functional and security requirements_/ that apply to the use of secure elements would need to be added. This might not be called "OAuth 2.0" anymore ... but this would be a secure solution. Denis > Hi Denis, > > The book is being published very shortly and the text is completed, so > there aren't any more updates to be made to it. Additionally, this > isn't really the forum for comments on the book (there's an online > form for discussion if you're interested: > https://forums.manning.com/forums/oauth-2-in-action), this is a list > for discussing and developing OAuth itself. Still, most of your > comments are general enough misconceptions of OAuth that they may be > of interest to others so I'll answer them on the list here, inline below. > > > On 2/2/2017 5:47 PM, Denis wrote: >> >> Justin, >> >> Your are making the promotion of your book (OAuth 2 In Action), soon >> to be published. >> >> I browsed through the 23 pages of Chapter 1 that are provided as a >> free download. >> >> I saw the footnote from Manning Publications Co. which states: >> >> "/We welcome reader comments about anything in the manuscript/" >> >> Since Manning Publications Co. asked for it, I hope that you will be >> able to take into consideration some of my comments before this book >> is published. >> >> I will only comment on a few sentences. >> >> 1. Page 1: "The application requests authorization from the owner of >> the resource and receivestokens that it can use to access the resource". >> >> Such a model is rather restrictive and does not cover the general >> case where an application is willing to perform an operation on a >> resource >> and where the resource tells to the application which kind of >> attributes need to be presented by the application for that specific >> operation. >> In such a case, the resource owner is not involved in anyway at the >> time of the request. If this restriction remains, this should be >> clearly stated. >> > > This is the model of OAuth: it's a delegation protocol, delegating > from a resource owner to a client. What you're describing is a > different protocol where the client and resource negotiate attributes > for the client to present to the resource to fulfill its requirements. > OAuth specifically abstracts that process using the authorization > server, and to great success. > >> 2. Page 10:" To acquire a token, the client first sends the resource >> owner to the authorization server in order to request that the >> resource owner authorize this client". >> >> This sentence is not English. You cannot "send the resource owner to >> the authorization server". This sentence should be rephrased. >> > > Yes you can send the resource owner to the authorization server -- > generally by redirecting their web browser to a page on the > authorization server (the authorization endpoint) for the resource > owner to interact with the authorization server. > >> 3. Page 16: "Even worse, some of the available options in OAuth can >> be taken in the wrong context or not enforced properly, leading to >> insecure implementations. >> These kinds of vulnerabilities are discussed at length in the OAuth >> Threat Model Document and the vulnerabilities section of this book >> (chapters 7, 8, 9, and 10)." >> >> Bear in mind that RFC 6819 was issued four years ago (in January >> 2013). Collusions between servers was considered, but collusions >> between clients was omitted, >> typically the ABC attack (Alice and Bob Collusion attack). See: >> https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html >> >> You should add some text in section 7.6 to deal with the ABC attack. >> > > Sharing bearer tokens is a well known attack surface and there's > really no way to stop that. Even PoP-style tokens can be shared since > nothing stops Bob and Alice from sharing their secrets with each > other. I've read everything you've written about the so-called ABC > attack and don't think there's more to say about it, especially in an > introductory book. > >> 4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it’s far >> from perfect. We will see its replacement at some point in the >> future, as with all things >> in technology, but no real contender has yet emerged as of the >> writing of this book. >> >> I can agree with you that "OAuth 2.0is far from perfect". Can a >> protocol with so many options be a "good protocol" ? Can >> interoperability be achieved ? >> I don't think so. You then say: " but no real contender has yet >> emerged as of the writing of this book". I would rather suggest that >> you delete >> " but no real contender has yet emerged as of the writing of this book". >> > > I address the optionality and interoperability issues in that chapter, > more in chapter 2, and even more in chapter 6. Yes, it's a good > protocol, and I'm sorry you don't like it. When there's a delegation > protocol that's similarly used across millions of sites and APIs all > over the internet, then we can talk about a real contender for > replacement. I look forward to that day, but we're not there yet (and > I don't think we're anywhere near there). > >> 5. Page 17: "OAuth assumes that the resource owner is the one that’s >> controlling the client". >> >> I do hope that it is not the case. The client should only be >> controlled by an end-user or by a local application and no one else. >> > > The resource owner *is* the end user. Your "should" is the same as the > assumption I'm stating. > >> >> 6. Page 17: " OAuth isn’t defined outside of the HTTP protocol. Since >> OAuth 2.0 with bearer tokens provides no message signatures, >> is it not meant to be used outside of HTTPS (HTTP over TLS). >> Sensitive secrets and information are passed over the wire, and >> OAuth requires a transport layer mechanism such as TLS to protect >> these secrets". >> >> The HTTPS protocol indeed needs to be used for resource data origin >> authentication and confidentiality protection of the data being >> exchanged. >> However, protecting sensitive secrets and information passed over the >> wire using TLS does not prevent in anyway an ABC attack. TLS binding >> does not provide either any extra protection in case of an ABC >> attack. This should be stated since this is an important issue. I >> really wonder >> if you can still say: " OAuth 2.0 is a good protocol". In any case, >> OAuth 2.0 is not a protocol but a framework. >> > > It doesn't prevent people from sharing secrets with each other out of > band, as we've just talked about, but it does prevent a whole raft of > other non-collusive attacks which are significantly more malicious and > problematic. > >> 7. Page 18: "OAuth doesn’t define a token format". >> >> How do you want to interoperate if no token format is being defined ? >> IETF RFCs on the standards track are primarily intended to be used to >> address interoperability. >> > > It all is based on *what* OAuth defines interoperability between. > OAuth says how a client talks to an AS and how a client talks to an > RS. It says nothing about how an RS and AS get along. Since the token > format is opaque to the client, OAuth defines no token format because > it didn't need to define one to be interoperable in the way it was > intended to be. > >> 8. Page 18 "In fact, the OAuth protocol explicitly states that the >> content of the token is completely opaque to the client application. >> >> This is even worse. In such a case, the client will be unable to make >> sure that what he got in the token is really what he was asking for: >> nothing more and nothing less. >> > > This is one of OAuth's best features, as it make things simpler. > >> 9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed >> previously, the specification is split into multiple definitions and >> flows, each of which has >> its own set of use cases. The core OAuth 2.0 specification has >> somewhat accurately been described as a security protocol generator, >> because it can be used >> to design the security architecture for many different use cases. As >> discussed in the previous section, these systems aren’t necessarily >> compatible with each other." >> >> This is indeed a very good description of the current mess. >> > > Yes, and I hope you read the rest of the paragraph that explains the > nature of that "mess" and why it's set up the way that it is. There's > a reason for it, which is why that section is there in the book. > >> 10. Section 15.2 is not provided. Its title is : *Proof of possession >> (PoP) tokens*. I am really curious to read how you can achieve PoP in >> the case of an ABC attack. >> > > That's in chapter 15, which you don't have because you haven't bought > the book. :) Same with all of the other forward references throughout > that section. > > And you can still share secrets if they're given to you in the PoP > case. Or you can just skip the security layer and share the results of > the API calls. There's literally nothing in the world that can prevent > that level of collusion -- PoP, token binding, DRM... nothing. > >> 11. I also observed that there is no chapter dealing with *privacy >> issues.* Nowadays, it is an important topic. In particular on how to >> prevent an authorization server >> to act as *Big Brother*. A section should be added to deal with >> privacy issues. >> > > This is a topic that has been covered in great depth on the web, and > since this is a technical book we didn't feel the need to get into it. > I encourage you to write a treatise yourself, please let us know when > you do. > >> 12. Finally a typo on page 18:"Since OAuth 2.0 with bearer tokens >> provides no message signatures, *is it*not meant to be used outside >> of HTTPS (HTTP over TLS)". >> > The preview chapters are not the latest copy of the manuscript text as > it's being prepared for final publication, so a lot of typos and > format errors have been fixed already. > > Thanks for the feedback, but as I said above, in the future please > don't bring up issues you have with the book on this mailing list. > > -- Justin > >> >> Denis >> >> >>> +1 to Phil's reference to SCIM, and since it looks like you're >>> looking to do end user authentication you should look at OpenID Connect: >>> >>> http://openid.net/connect/ >>> >>> There are a lot of ways to get an authentication protocol based on >>> OAuth very, very wrong, and I've covered some of the big ones in an >>> article I wrote (with the community's help) a few years ago: >>> >>> http://oauth.net/articles/authentication/ >>> >>> Furthermore, I've covered the topic in my upcoming book, OAuth 2 In >>> Action, which you might find useful: >>> >>> https://www.manning.com/books/oauth-2-in-action >>> >>> All said, the space is not as easy as you may think it is at first >>> and there are a lot of pitfalls. But the good news is that you're >>> not the first to dive in here and there are a lot of really good >>> solutions already available. >>> >>> -- Justin >>> >>> >>> On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote: >>>> You are headed down the road to a very big domain called identity >>>> management and provisioning. >>>> >>>> You might want to look at SCIM (RFC7643, 7644) for a restful api >>>> pattern. >>>> >>>> SCIM is usually OAuth enabled but the scopes/rights have not yet >>>> been standardized. There is however some obvious access control >>>> patterns that apply from the old ldap directory world. >>>> >>>> Phil >>>> >>>> On Feb 1, 2017, at 6:36 PM, Yunqi Zhang >>> > wrote: >>>> >>>>> Hi all, >>>>> >>>>> I'm working on a set of API endpoints to allow institutions to >>>>> manage their users and records, and their users to read their own >>>>> records. >>>>> >>>>> Specifically, each institution will get a {client_id} and a >>>>> {secret} after registering with us, which allows them to create >>>>> users under its institution using [POST https://hostname/users/]. >>>>> Then the institution can also insert records for each user using >>>>> [POST https://hostname/users/:user_id/]. Once a user has been >>>>> created, he/she can read his/her own records using [GET >>>>> https://hostname/users/:user_id/]. >>>>> >>>>> In this process, there are two types of authentications I would >>>>> like to achieve, which I'm thinking about using oauth. However, I >>>>> am super new on oauth and have four questions. >>>>> >>>>> Institution authentication (e.g., company FOO will have READ and >>>>> WRITE access to https://hostname/ to create users under its own >>>>> institution, insert records for specific users): (1) Since this >>>>> part of the system will be created and run by the institution, >>>>> this should be a "client credential grant" using {client_id} and >>>>> {secret} of the institution, correct? >>>>> >>>>> End-user authentication (e.g., user John Doe of company FOO will >>>>> have READ access to https://hostname/users/:john_doe_user_id/ to >>>>> read his own personal records): (2) Because this part of the >>>>> system will probably run on the web/mobile app created by company >>>>> FOO, this should be a "resource owner credential grant" using >>>>> {username}, {password} of the specific user, correct? >>>>> >>>>> (3) Because I am allow two types of different authentications, >>>>> which will use two types of different {access_token}s I assume, >>>>> would that be something weird (or hard to build) under the oauth >>>>> model? >>>>> >>>>> (4) What if the web/mobile app created by a subset of the >>>>> companies already has its own authentication and does not want to >>>>> create another password for each of its users, what should I do? >>>>> For example, company FOO has its own authentication for its >>>>> web/mobile app and does not want to bother creating another >>>>> password for each of its user (i.e., requires only {username}), >>>>> whereas company BAR would like to create another password for each >>>>> user (i.e., requires {username} and {password}). What kind of >>>>> authentication model should I use for a scenario like this? >>>>> >>>>> Thank you very much for your help! >>>>> >>>>> Yunqi >>>> --------------310C5A4D40FAE297B2BB215D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Justin,

You said :

"Sharing bearer tokens is a well known attack surface and there's really no way to stop that.
  Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other".

You also said:

"There's literally nothing in the world that can prevent that level of collusion -- PoP, token binding, DRM... nothing".


Whatever kind of cryptography is being used, there is indeed are no way to stop sharing bearer tokens using implementations
that rely on software-only implementations.

Since the current documents being progressed in the Tokbind WG are based on the use of software only (i.e. TLS binding),
none of them is able to prevent that level of collusion.

Note: I also send a copy of the email to the Tokbind WG (unbearable@ietf.org) so that it can be aware of that discussion.

However, when using secure hardware in a right way, it is possible to stop sharing bearer tokens.

Idemix from IBM has been extended to take advantage of the use of smart cards. See the IRMA project (I Reveal My Attributes)
at: https://www.irmacard.org/irma/

It is mentioned in particular that "The security of IRMA depends on the protection of each User’s private key".

Bob cannot indeed transmit any private key to Alice, however he is able to use private keys present in his smart card.
If Bob accepts to collaborate with Alice, a smart card simply protecting private keys does not possess sufficient properties
to counter the ABC attack (Alice and Bob Collusion attack). Bob can perform all the computations that Alice needs, even if Bob
and Alice are located in different continents.

Hence the IRMA project, based on Idemix, is vulnerable to the ABC attack.

Another solution from Microsoft (U-Prove) has the same problem, even when smart cards (or secure elements) are being used:
U-prove is also vulnerable to the ABC attack.

draft-ietf-oauth-pop-architecture-08 (OAuth 2.0 Proof-of-Possession (PoP) Security Architecture), has expired on January 9, 2017.
Since it was only relying on software, it was unable to counter the ABC attack.

The only way to stop sharing bearer tokens is to use implementations that rely on some piece of hardware that has additional properties
beyond the protection of private keys.

A secure solution certainly needs to rely on the use of software, but also on the use of secure elements that have specific functional and security properties.

Stopping the sharing of bearer tokens, is not a concern in the case of a delegation protocol, since the use of Authorization Servers should be deprecated
in this context for privacy reasons (as explained in my previous email sent to the OAuth mailing list).

However, stopping the sharing of bearer tokens is mandatory in a "different protocol where the client and resource negotiate attributes for the client
to present to the resource to fulfill its requirements".

A protocol able to stop sharing bearer tokens needs to transmit data generated by the secure elements (called APDUs - Application Protocol Data Units)
so that some APDUs can be directly verified by Authorization Servers and some other APDUs can be directly verified by Resource Servers.

In order to stop the sharing of bearer tokens, it is also necessary to specify the format of the access tokens.

I noticed that OAuth does not specify the access token itself, since the format is opaque to the protocol flow. As long as this postulate will remain,
OAuth and its derivatives won't be able to stop the sharing of bearer tokens.

As a conclusion, keeping all the postulates of OAuth 2.0 unchanged, I do agree with you that "there's really no way to stop that".

However, there's a way to stop that, but some of the postulates of OAuth 2.0 would need to be changed and some functional and security requirements
that apply to the use of secure elements would need to be added.

This might not be called "OAuth 2.0" anymore ... but this would be a secure solution.

Denis


Hi Denis,

The book is being published very shortly and the text is completed, so there aren't any more updates to be made to it. Additionally, this isn't really the forum for comments on the book (there's an online form for discussion if you're interested: https://forums.manning.com/forums/oauth-2-in-action), this is a list for discussing and developing OAuth itself. Still, most of your comments are general enough misconceptions of OAuth that they may be of interest to others so I'll answer them on the list here, inline below.


On 2/2/2017 5:47 PM, Denis wrote:

Justin,

Your are making the promotion of your book (OAuth 2 In Action), soon to be published.

I browsed through the 23 pages of Chapter 1 that are provided as a free download.

I saw the footnote from Manning Publications Co. which states:

"We welcome reader comments about anything in the manuscript"

Since Manning Publications Co. asked for it, I hope that you will be able to take into consideration some of my comments before this book is published.

I will only comment on a few sentences.

1. Page 1: "The application requests authorization from the owner of the resource and receives tokens that it can use to access the resource".

Such a model is rather restrictive and does not cover the general case where an application is willing to perform an operation on a resource
and where the resource tells to the application which kind of attributes need to be presented by the application for that specific operation.
In such a case, the resource owner is not involved in anyway at the time of the request. If this restriction remains, this should be clearly stated.


This is the model of OAuth: it's a delegation protocol, delegating from a resource owner to a client. What you're describing is a different protocol where the client and resource negotiate attributes for the client to present to the resource to fulfill its requirements. OAuth specifically abstracts that process using the authorization server, and to great success.

2. Page 10:" To acquire a token, the client first sends the resource owner to the authorization server in order to request that the resource owner authorize this client".

This sentence is not English. You cannot "send the resource owner to the authorization server". This sentence should be rephrased.


Yes you can send the resource owner to the authorization server -- generally by redirecting their web browser to a page on the authorization server (the authorization endpoint) for the resource owner to interact with the authorization server.

3. Page 16: "Even worse, some of the available options in OAuth can be taken in the wrong context or not enforced properly, leading to insecure implementations.
These kinds of vulnerabilities are discussed at length in the OAuth Threat Model Document and the vulnerabilities section of this book (chapters 7, 8, 9, and 10)."

Bear in mind that RFC 6819 was issued four years ago (in January 2013). Collusions between servers was considered, but collusions between clients was omitted,
typically the ABC attack (Alice and Bob Collusion attack). See: https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html

You should add some text in section 7.6 to deal with the ABC attack.


Sharing bearer tokens is a well known attack surface and there's really no way to stop that. Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other. I've read everything you've written about the so-called ABC attack and don't think there's more to say about it, especially in an introductory book.

4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it’s far from perfect. We will see its replacement at some point in the future, as with all things
in technology, but no real contender has yet emerged as of the writing of this book.

I can agree with you that "OAuth 2.0 is far from perfect". Can a protocol with so many options be a "good protocol" ? Can interoperability be achieved ?
I don't think so. You then say: " but no real contender has yet emerged as of the writing of this book". I would rather suggest that you delete
" but no real contender has yet emerged as of the writing of this book".


I address the optionality and interoperability issues in that chapter, more in chapter 2, and even more in chapter 6. Yes, it's a good protocol, and I'm sorry you don't like it. When there's a delegation protocol that's similarly used across millions of sites and APIs all over the internet, then we can talk about a real contender for replacement. I look forward to that day, but we're not there yet (and I don't think we're anywhere near there).

5. Page 17: "OAuth assumes that the resource owner is the one that’s controlling the client".

I do hope that it is not the case. The client should only be controlled by an end-user or by a local application and no one else.


The resource owner *is* the end user. Your "should" is the same as the assumption I'm stating.


6. Page 17: " OAuth isn’t defined outside of the HTTP protocol. Since OAuth 2.0 with bearer tokens provides no message signatures,
is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive secrets and information are passed over the wire, and
OAuth requires a transport layer mechanism such as TLS to protect these secrets".

The HTTPS protocol indeed needs to be used for resource data origin authentication and confidentiality protection of the data being exchanged.
However, protecting sensitive secrets and information passed over the wire using TLS does not prevent in anyway an ABC attack. TLS binding
does not provide either any extra protection in case of an ABC attack. This should be stated since this is an important issue. I really wonder
if you can still say: " OAuth 2.0 is a good protocol". In any case, OAuth 2.0 is not a protocol but a framework.


It doesn't prevent people from sharing secrets with each other out of band, as we've just talked about, but it does prevent a whole raft of other non-collusive attacks which are significantly more malicious and problematic.

7. Page 18: "OAuth doesn’t define a token format".

How do you want to interoperate if no token format is being defined ? IETF RFCs on the standards track are primarily intended to be used to address interoperability.


It all is based on *what* OAuth defines interoperability between. OAuth says how a client talks to an AS and how a client talks to an RS. It says nothing about how an RS and AS get along. Since the token format is opaque to the client, OAuth defines no token format because it didn't need to define one to be interoperable in the way it was intended to be.

8. Page 18 "In fact, the OAuth protocol explicitly states that the content of the token is completely opaque to the client application.

This is even worse. In such a case, the client will be unable to make sure that what he got in the token is really what he was asking for: nothing more and nothing less.


This is one of OAuth's best features, as it make things simpler.

9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed previously, the specification is split into multiple definitions and flows, each of which has
its own set of use cases. The core OAuth 2.0 specification has somewhat accurately been described as a security protocol generator, because it can be used
to design the security architecture for many different use cases. As discussed in the previous section, these systems aren’t necessarily compatible with each other."

This is indeed a very good description of the current mess.


Yes, and I hope you read the rest of the paragraph that explains the nature of that "mess" and why it's set up the way that it is. There's a reason for it, which is why that section is there in the book.

10. Section 15.2 is not provided. Its title is : Proof of possession (PoP) tokens. I am really curious to read how you can achieve PoP in the case of an ABC attack.


That's in chapter 15, which you don't have because you haven't bought the book. :) Same with all of the other forward references throughout that section.

And you can still share secrets if they're given to you in the PoP case. Or you can just skip the security layer and share the results of the API calls. There's literally nothing in the world that can prevent that level of collusion -- PoP, token binding, DRM... nothing.

11. I also observed that there is no chapter dealing with privacy issues. Nowadays, it is an important topic. In particular on how to prevent an authorization server
to act as Big Brother. A section should be added to deal with privacy issues.


This is a topic that has been covered in great depth on the web, and since this is a technical book we didn't feel the need to get into it. I encourage you to write a treatise yourself, please let us know when you do.

12. Finally a typo on page 18: "Since OAuth 2.0 with bearer tokens provides no message signatures, is it not meant to be used outside of HTTPS (HTTP over TLS)".

The preview chapters are not the latest copy of the manuscript text as it's being prepared for final publication, so a lot of typos and format errors have been fixed already.

Thanks for the feedback, but as I said above, in the future please don't bring up issues you have with the book on this mailing list.

 -- Justin


Denis


+1 to Phil's reference to SCIM, and since it looks like you're looking to do end user authentication you should look at OpenID Connect:

http://openid.net/connect/

There are a lot of ways to get an authentication protocol based on OAuth very, very wrong, and I've covered some of the big ones in an article I wrote (with the community's help) a few years ago:

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

Furthermore, I've covered the topic in my upcoming book, OAuth 2 In Action, which you might find useful:

https://www.manning.com/books/oauth-2-in-action

All said, the space is not as easy as you may think it is at first and there are a lot of pitfalls. But the good news is that you're not the first to dive in here and there are a lot of really good solutions already available.

 -- Justin


On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote:
You are headed down the road to a very big domain called identity management and provisioning. 

You might want to look at SCIM (RFC7643, 7644) for a restful api pattern.

SCIM is usually OAuth enabled but the scopes/rights have not yet been standardized. There is however some obvious access control patterns that apply from the old ldap directory world.  

Phil

On Feb 1, 2017, at 6:36 PM, Yunqi Zhang <zhangyunqi.cs@gmail.com> wrote:

Hi all,

I'm working on a set of API endpoints to allow institutions to manage their users and records, and their users to read their own records.

Specifically, each institution will get a {client_id} and a {secret} after registering with us, which allows them to create users under its institution using [POST https://hostname/users/]. Then the institution can also insert records for each user using [POST https://hostname/users/:user_id/]. Once a user has been created, he/she can read his/her own records using [GET https://hostname/users/:user_id/].

In this process, there are two types of authentications I would like to achieve, which I'm thinking about using oauth. However, I am super new on oauth and have four questions.

Institution authentication (e.g., company FOO will have READ and WRITE access to https://hostname/ to create users under its own institution, insert records for specific users): (1) Since this part of the system will be created and run by the institution, this should be a "client credential grant" using {client_id} and {secret} of the institution, correct?

End-user authentication (e.g., user John Doe of company FOO will have READ access to https://hostname/users/:john_doe_user_id/ to read his own personal records): (2) Because this part of the system will probably run on the web/mobile app created by company FOO, this should be a "resource owner credential grant" using {username}, {password} of the specific user, correct?

(3) Because I am allow two types of different authentications, which will use two types of different {access_token}s I assume, would that be something weird (or hard to build) under the oauth model?

(4) What if the web/mobile app created by a subset of the companies already has its own authentication and does not want to create another password for each of its users, what should I do? For example, company FOO has its own authentication for its web/mobile app and does not want to bother creating another password for each of its user (i.e., requires only {username}), whereas company BAR would like to create another password for each user (i.e., requires {username} and {password}). What kind of authentication model should I use for a scenario like this?

Thank you very much for your help!

Yunqi


--------------310C5A4D40FAE297B2BB215D-- From nobody Mon Feb 6 04:02:27 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220FB129CEA for ; Mon, 6 Feb 2017 04:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVPyum-54Y4D for ; Mon, 6 Feb 2017 04:02:23 -0800 (PST) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 18B3112952F for ; Mon, 6 Feb 2017 04:02:23 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id 89so21985393wrr.2 for ; Mon, 06 Feb 2017 04:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FpgpNm9yKy11y+BnOKcA/4KLugufhq54RA501Q8Bst8=; b=ckqR69WIwpus9NFkzKKJmVvzCUnocul4BvHvwokZ8maWdxKG426iROk2YtBXhuTGhy TqSdGSQwjT1MbaWBAdONGsHIqoqbU15lMbvQUZqb3UV/n/FG1jTcSCOGRwQVS2VDOVnG qdQRaLU1hnoG90UE7UR3SL1XBzTBEsSTq+lFsootwUzzWUS6TFACtTNAHjEDav1yniNP IbkFYmd6jRTHVGs2n0MjhKZheOaxYwHw/LWRB7r1lF03kCZJb5tDmZNbYZDCSBe23uk3 JPHVUbzzSC/LMvcJlKC/t3egtoIIA3Y7f+ZtibVk2aXo24NbC+Xz0x7iohd0VVnu096A VZwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FpgpNm9yKy11y+BnOKcA/4KLugufhq54RA501Q8Bst8=; b=lwMqVv/ls2UtIiZWZFHGoYkxPR7wdQYO05u1Bp50POW5onSE6cTYjaoLVYMaNf+DPv 6FYW4c4gfYvEUrikzCgPCkZJutBDlrNA2mLmjNgVFgRBo+CwAVX1UyU5tolCgdGVBml3 lzWLsd7SewmOToeJEV4NgdaVhDcCL7XXxNxyVObB8/qabdsJOpkdxoK3Y1hoBOqyIt/w vLEqlvndvz22kzIFjcenL8FxJdSRk+iS88IoMAZm2Wgl1C8ma3g8g7+BTN/o9NL64/yx 9GQR3RaGP998hfaPwN6UyckQGvrxaI9tgzWiYt8eZzvlKleAQwfG5HcKBuDk9ma1sfyZ azGw== X-Gm-Message-State: AIkVDXKRqLIg1r6vWXu8eMsYFUQbEJR23FX6K5IbXRmIKsojxi7k22VNZ4wpThRIi17tmnKoWdtrOG2/w0/7Gw== X-Received: by 10.223.167.71 with SMTP id e7mr8908319wrd.154.1486382540079; Mon, 06 Feb 2017 04:02:20 -0800 (PST) MIME-Version: 1.0 References: <541A5105-B963-4FA4-94E4-D794A73B3358@ve7jtb.com> <14c5b7d3-9faa-0e2f-1411-689ab13d4fad@manicode.com> In-Reply-To: <14c5b7d3-9faa-0e2f-1411-689ab13d4fad@manicode.com> From: Nat Sakimura Date: Mon, 06 Feb 2017 12:02:08 +0000 Message-ID: To: Jim Manico , William Denniss Content-Type: multipart/alternative; boundary=94eb2c1cc94a4d48bd0547db678f Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 12:02:25 -0000 --94eb2c1cc94a4d48bd0547db678f Content-Type: text/plain; charset=UTF-8 A belated +1 On Sat, Feb 4, 2017, 9:08 AM Jim Manico wrote: > I'm just some random idiot am an not in this working group but the work > from > https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 is > one of the most up to date and useful OAuth security resources every > published. I am thrilled to see more work put into it. > > Aloha, Jim > > On 2/3/17 1:57 PM, William Denniss wrote: > > I support the adoption of this document as a working group item. > > On Thu, Feb 2, 2017 at 2:30 PM, Jim Willeke wrote: > > +! > I agree this is needed. > > -- > -jim > Jim Willeke > > On Thu, Feb 2, 2017 at 4:33 PM, John Bradley wrote: > > I am in favour of adoption. > > On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig > wrote: > > > > Hi all, > > > > this is the call for adoption of the 'OAuth Security Topics' document > > following the positive call for adoption at the last IETF > > meeting in Seoul. > > > > Here is the document: > > https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 > > > > The intention with this document is to have a place to collect > > discussions and conclusions around OAuth 2.0 security and to reference > > the actual solution specifications. > > > > Please let us know by Feb 16th whether you accept / object to the > > adoption of this document as a starting point for work in the OAuth > > working group. > > > > Ciao > > Hannes & Derek > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > -- > Jim Manico > Manicode Securityhttps://www.manicode.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation --94eb2c1cc94a4d48bd0547db678f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

A belated +1


On Sat, Feb 4, 2017, 9:08 A= M Jim Manico <jim@manicode.com&g= t; wrote:
=20 =20 =20

I'm just some random idiot am an not in this= working group but the work from https://tools.ietf.org/html/draft-lodderstedt-oauth-security-to= pics-00 is one of the most up to date and useful OAuth security resources every published. I am thrilled to see more work put into it.

Aloha, Jim


On 2/3/17= 1:57 PM, William Denniss wrote:
I support the adoption of this d= ocument as a working group item.

On Thu, Feb 2, 2017 at 2:30 PM= , Jim Willeke <jim@willeke.com> wrote:
+!=C2=A0
I agree this is needed.

--
-jim
Jim Willeke

On Thu, Feb 2, 2017 = at 4:33 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
I am in favour of adoption.
> On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
> Hi all,
>
> this is the call for adoption of the 'OAuth Security Topics' document
> following the positive call for adoption at the last IETF
> meeting in Seoul.
>
> Here is the document:
> https://tools.ietf.org/html/draft-lodderstedt-oauth-se= curity-topics-00
>
> The intention with this document is to have a place to collect
> discussions and conclusions around OAuth 2.0 security and to reference
> the actual solution specifications.
>
> Please let us know by Feb 16th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Derek
>
> _______________________________________________ > OAuth mailing list
> OAuth@ietf.org
> https:= //www.ietf.org/mailman/listinfo/oauth


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



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




____________________________________________=
___
OAuth mailing list
OAuth@ietf.org
https://www.i=
etf.org/mailman/listinfo/oauth

--=20 Jim Manico Manicode Security https://www.manicode.com
_______________________________________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--94eb2c1cc94a4d48bd0547db678f-- From nobody Mon Feb 6 04:30:27 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5286C129D31 for ; Mon, 6 Feb 2017 04:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEnvZvTzFIUu for ; Mon, 6 Feb 2017 04:30:24 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 79B581293EB for ; Mon, 6 Feb 2017 04:30:24 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 89B2C78037F for ; Mon, 6 Feb 2017 13:30:21 +0100 (CET) To: oauth@ietf.org References: <541A5105-B963-4FA4-94E4-D794A73B3358@ve7jtb.com> <14c5b7d3-9faa-0e2f-1411-689ab13d4fad@manicode.com> From: Denis Message-ID: <0a8ab2ad-9f14-6915-464f-119a724422c7@free.fr> Date: Mon, 6 Feb 2017 13:30:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B90367528D5F66A84CAC7FEA" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 12:30:26 -0000 This is a multi-part message in MIME format. --------------B90367528D5F66A84CAC7FEA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit The scope of this draft is unclear. The title states: "OAuth Security Topics".** I have some questions: * Does this document intend to cover only the OAuth 2.0 delegation protocol (since Justin said that OAuth 2.0 is a delegation protocol) or OpenId Connect as well which is not limited to a delegation protocol ? * Should we discuss OpenID Connect issues and/or solutions in an IETF RFC ? If this document is going to be progressed, the threats should be clearly separated whether they relate to a delegation model or to a client-server access control model. This is not currently the case. If this document is going to be progressed, the ABC attack (in the context of an access control model) should be mentioned even if there exits no way to counter it given the current implicit assumptions made in OAuth 2.0, in particular the use of software only implementations. Denis > A belated +1 > > > On Sat, Feb 4, 2017, 9:08 AM Jim Manico > wrote: > > I'm just some random idiot am an not in this working group but the > work from > https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 > is one of the most up to date and useful OAuth security resources > every published. I am thrilled to see more work put into it. > > Aloha, Jim > > > On 2/3/17 1:57 PM, William Denniss wrote: >> I support the adoption of this document as a working group item. >> >> On Thu, Feb 2, 2017 at 2:30 PM, Jim Willeke > > wrote: >> >> +! >> I agree this is needed. >> >> -- >> -jim >> Jim Willeke >> >> On Thu, Feb 2, 2017 at 4:33 PM, John Bradley >> > wrote: >> >> I am in favour of adoption. >> > On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig >> > > wrote: >> > >> > Hi all, >> > >> > this is the call for adoption of the 'OAuth Security >> Topics' document >> > following the positive call for adoption at the last IETF >> > meeting in Seoul. >> > >> > Here is the document: >> > >> https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 >> > >> > The intention with this document is to have a place to >> collect >> > discussions and conclusions around OAuth 2.0 security >> and to reference >> > the actual solution specifications. >> > >> > Please let us know by Feb 16th whether you accept / >> object to the >> > adoption of this document as a starting point for work >> in the OAuth >> > working group. >> > >> > Ciao >> > Hannes & Derek >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > -- > Jim Manico > Manicode Security > https://www.manicode.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------B90367528D5F66A84CAC7FEA Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


The scope of this draft is unclear. The title states: "OAuth Security Topics".

I have some questions:

  • Does this document intend to cover only the OAuth 2.0 delegation protocol (since Justin said that OAuth 2.0 is a delegation protocol)
    or OpenId Connect as well which is not limited to a delegation protocol ?
  • Should we discuss OpenID Connect issues and/or solutions in an IETF RFC ?

If this document is going to be progressed, the threats should be clearly separated whether they relate to a delegation model or to
a client-server access control model. This is not currently the case.

If this document is going to be progressed, the ABC attack (in the context of an access control model) should be mentioned even if there exits
no way to counter it given the current implicit assumptions made in OAuth 2.0, in particular the use of software only implementations.


Denis

A belated +1


On Sat, Feb 4, 2017, 9:08 AM Jim Manico <jim@manicode.com> wrote:

I'm just some random idiot am an not in this working group but the work from https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 is one of the most up to date and useful OAuth security resources every published. I am thrilled to see more work put into it.

Aloha, Jim


On 2/3/17 1:57 PM, William Denniss wrote:
I support the adoption of this document as a working group item.

On Thu, Feb 2, 2017 at 2:30 PM, Jim Willeke <jim@willeke.com> wrote:
+! 
I agree this is needed.

--
-jim
Jim Willeke

On Thu, Feb 2, 2017 at 4:33 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I am in favour of adoption.
> On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
> Hi all,
>
> this is the call for adoption of the 'OAuth Security Topics' document
> following the positive call for adoption at the last IETF
> meeting in Seoul.
>
> Here is the document:
> https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00
>
> The intention with this document is to have a place to collect
> discussions and conclusions around OAuth 2.0 security and to reference
> the actual solution specifications.
>
> Please let us know by Feb 16th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Derek
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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



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




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


-- 
Jim Manico
Manicode Security
https://www.manicode.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--

Nat Sakimura

Chairman of the Board, OpenID Foundation



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


--------------B90367528D5F66A84CAC7FEA-- From nobody Mon Feb 6 06:09:00 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BAF129D9E; Mon, 6 Feb 2017 06:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGFlx4iSpGID; Mon, 6 Feb 2017 06:08:51 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 92370129D9B; Mon, 6 Feb 2017 06:08:47 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id u63so22148660wmu.2; Mon, 06 Feb 2017 06:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A4rhqcW25zvyCoENP7OoIdv6Zho/7dwIh2/yN0yP9BY=; b=q4AA87o5KvhbPCo8DNGGh35B0t7pl5B1SxCZafGGlsoSIGuequFnZXlPLjgi0IyCuz JXwZCeTs2b2FvI8C45ouwsOIBWDJWoQE6CD1TGE6pbCTmZDVeyMoSdkiFDBDik2cxOZu VZrYtjSfB0KBnQ+P44Uyv69vQcqn40ZKgc7GfD6R25A4FxdVM/kBZOqCOyfdUbICM7xV TY9ij9MaFVP4V5JbOsH92EMZv/BsVhd2zOMwxlubz1TNxq3swoKPfwe+30XYQqMk9/dk kz9ctqdWokjuCRkk8FRetjBpU2Lefcn+gmEN+T6NIodCA/UEYQx7bkWRKsmAwhFQgtyr Sp1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A4rhqcW25zvyCoENP7OoIdv6Zho/7dwIh2/yN0yP9BY=; b=nFdbVyrJpt8rZvUcesUa70gniScSQ0jrQgvl0WgZpxmUSJ/NHvTGM8JeY/gMuLmXlx eEOfTVdOYW6ZhYFxNMmlJhmdi1c9FMjfqD80/locfoncuYpT2mIr1j9jDOLvx0mxdUl7 IA89x6pg7KLF95k4ql5ljHkyMCIhw5nNUcpP33iagsOWrReJydu8RahJ2Si6rJCrZmJD da3K9h3phKzQfgBymw1hmrJ4UUpyiimavI9YNBFr1Nt5oTLo/2xWPzUObc6buNd7y/ft THJ+kIsEwLcLTxNMPLwZHSs/q04/slXYT2RgevS7Q0pxIb0e75s4x3M7lYRtW7K7Wbr5 HhVA== X-Gm-Message-State: AMke39mzS1mywk73Y8lVg7I6TGXxeOPlc5V1fx/MVFI+0TjEU0CwjNtRhg7z2pS5gPFc4wXbzLQH5UUvPr2Zaw== X-Received: by 10.28.38.2 with SMTP id m2mr8390283wmm.44.1486390125875; Mon, 06 Feb 2017 06:08:45 -0800 (PST) MIME-Version: 1.0 References: <148581788158.29828.4591033587037530374.idtracker@ietfa.amsl.com> <3a6b8cee-ff29-323e-9042-5df6e71a8d81@free.fr> In-Reply-To: <3a6b8cee-ff29-323e-9042-5df6e71a8d81@free.fr> From: Nat Sakimura Date: Mon, 06 Feb 2017 14:08:34 +0000 Message-ID: To: Denis , ietf@ietf.org, IETF-Announce Content-Type: multipart/alternative; boundary=94eb2c03fb967359de0547dd2b76 Archived-At: Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 14:08:54 -0000 --94eb2c03fb967359de0547dd2b76 Content-Type: text/plain; charset=UTF-8 Thanks Denis. Here is my proposed disposition on your comments. On Fri, Feb 3, 2017 at 8:11 PM Denis wrote: > *Comments on I-D Action: draft-ietf-oauth-jwsreq-11.txt* > > > > Two editorial comments first : > > > > 1. Guidance is a mass noun, not a count noun, plural doesn't make sense. > Please change "guidances" into "guidance" twice in Section 11. > Accepted. Thanks. > > > 2. In Section 12 : Please remove my name (Denis Pinkas) from this section. > Accepted. > > > Other comments: > > > > 3. Section 1.1 (from boiler plate) states: The key words "MUST", "MUST > NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", > "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to > be interpreted as described in RFC 2119 [RFC2119]. > > There is not a single other occurrence of the word SHALL within this > document. In such case, I wonder how this document can be normative. > There are however many (useful) "non-normative examples. A non-normative > example does not replace requirements. > > Noted. There are bunch of MUST. At IETF we usually prefer MUST to SHALL, unlike in ISO. > > > Section 4 states: > > > > * A Request Object (Section 2.1) is used to provide authorization* > > * request parameters for an OAuth 2.0 authorization request. It* > > * contains OAuth 2.0 [RFC6749] authorization request parameters* > > * including extension parameters**. * > > > > RFC 6749 contains 75 pages, but does not contain a single occurrence of > the wording "authorization request parameter" nor of "extension parameter". > There should be either references to one or more specific sections of this > document or, even better, a list of the mandatory/recommended/possible > authorization request parameters as well as a list of > mandatory/recommended/possible extension parameters should be included in > this document. > > > A clear distinction should be made between the parameters used to > authenticate the request and the other ones. > Reject. There are 4 flows in RFC6749. In each flow, there is a sub-section dedicated to the Authorization request. In them, the parameters used in the authorization request are very clearly indicated. For example, 4.1.1 . Authorization Request The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI ... It is very difficult to miss. Then, the possibility for the extension parameters are discussed in 8.2. Needless to say, those extension parameters are going to be discussed in other specifications. Thus, it would be misleading just to say the parameters defined in 4.1.1, 4.2.1, etc. As an editor, I feel better with the current language because it is at least not wrong nor misleading. > > > 4. The introduction states on page 4: > > > > (a) (integrity protection) The request can be signed so that the > integrity of the request can be checked ; > > > > This should be changed into: > > > > (a) (integrity protection) The request can be authenticated either > using a digital signature or using encryption under a secret key > so that the integrity of the request can be checked ; > Reject. This paragraph is talking about the integrity protection and not the source authentication. And even for source authentication, saying that encryption under a secret key is not accurate as it was discussed earlier in the WG mail. I am not sure if "Introduction" needs to state everything that is explained later. The idea of introduction probably is to give main points. The list is not an exhaustive list of the benefit of using JWT as the authorization request format. For example, being able to encrypt the request, which is not listed there, has an advantage of preventing MITB to eavesdrop the request. So I think it is ok as is. > > > 5. The introduction states on page 4: > > > > (d) (collection minimization) The request can be *signed* by a third > party attesting that the authorization request is compliant to certain > policy. > > The request is not *signed* by a third party. > However, later on, there is the following explanation: > > > > In addition, it allows requests to be prepared by a third party so > that a client application cannot request > more permissions than previously agreed. > > > > If it is the intent, the sentence should be rephrased as: > > > > (d) (collection minimization) The request can be *verified* by a third > party attesting that the authorization request is compliant to certain > policy. > > > Reject The third party indeed signs the request on behalf of the client as the result of verification that the permission is the same as previously agreed. > > > 6. Section 10.1. the text states: > > > > * When sending the authorization request object through "request"* > > * parameter, it MUST either be signed using JWS [RFC7515] or encrypted* > > * using JWE [RFC7516] with then considered appropriate algorithm.* > > > > The wording" with then considered appropriate algorithm" is too vague. > This should be changed into: > > > > * When sending the authorization request object through "request"* > > * parameter, it MUST either be signed using JWS [RFC7515] or encrypted* > > * using JWE [RFC7516] using a symmetric key algorithm.* > > > Reject. In the above sentence, "*with then considered appropriate algorithm*" applies both on JWS and JWE. The intent of the phrase is that a vulnerable algorithm should not be used. Also, I do not understand why the algorithm has to be symmetric key algorithm. > > > 7. Section 10.2 states: > > > > This means that the request object is going to be prepared fresh each > > time an authorization request is made and caching cannot be used. > > > > What are the implications ? Is it required/recommended to use a nonce ? > The text should be made clearer. > > Reject. The implication is given right after the sentence. There is no variable called "nonce" in RFC6749. Since this document is just defining another encoding method for OAuth 2.0 authorization request as a framework, it does not mandate these. An extension specification should define those requirements. > > > 8. Section 10.3 states: > > > > 10.3. Request Source Authentication > > > > The source of the Authorization Request MUST always be verified. > > There are several ways to do it in this specification. > > > > (a) Verifying the JWS Signature of the Request Object. > > > > It seems that the case of using a JWE encrypted using a secret key > algorithm has been forgotten here. Please add it. > Accepted with modification. You mean, symmetric key algorithm, is that right? I would add "or verifying that the symmetric key for the JWE encryption is a correct one" > > > 9. Section 10.3 states at its very end: > > > > An extension specification > > should be created as a preventive measure to address potential > > vulnerabilities that have not yet been identified. > > > > Writing a document for vulnerabilities that have not yet been identified > is speculative. It would rather be better > either to remove this sentence or to explain what is meant by it. > Reject. It is referring to the first paragraph of the sub-section. Also, precaution when security is in question is a good thing. > 10. Section 11.1 states: > > > > *11.1. Collection limitation* > > > > * When the Client is being granted access to a protected resource* > > * containing personal data, the Client SHOULD limit the collection of* > > * personal data to that which is within the bounds of applicable law* > > * and strictly necessary for the specified purpose(s).* > > > > The *presentation* of personal data should be limited whether or not the > protected resource contains personal data. > > It is proposed to change this text into: > > > > * When the Client requests an access to a protected resource, the Client* > > * SHOULD limit the presentation of personal data to that which is within > * > > * the bounds of applicable law and strictly necessary for the specified * > > * purpose(s).* > Reject. You are not getting what OAuth does. The party that holds personal data is the authorization server / resource. It is not the client. The client is the party who is getting those "resources" which may contain personal data. Yes, the client can provide some personal data to the resource depending on what that resource endpoint is, but that is out of scope for OAuth. As far as OAuth is concerned, what is being sent from the client to the resource is the access token. > > > 11. Section 11.2.1 states: > > > > 11.2.1. Request Disclosure > > > > This specification allows extension parameters. > > > > It would be useful to name either all of them or some of them. RFC 6749 is > not crystal clear about this. > Noted. RFC6749 only defines how to define extension parameters. This specification draws from OpenID Connect for some examples of extension parameters such as nonce. See section 4 for example. > > > > Denis Pinkas (DP Security Consulting SAS) > > > ============================================================== > > > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization > Request (JAR)' > 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 theietf@ietf.org mailing lists by 2017-02-13. 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 > > > The authorization request in OAuth 2.0 described in RFC 6749 utilizes > query parameter serialization, which means that Authorization Request > parameters are encoded in the URI of the request and sent through > user agents such as web browsers. While it is easy to implement, it > means that (a) the communication through the user agents are not > integrity protected and thus the parameters can be tainted, and (b) > the source of the communication is not authenticated. Because of > these weaknesses, several attacks to the protocol have now been put > forward. > > This document introduces the ability to send request parameters in a > JSON Web Token (JWT) instead, which allows the request to be JWS > signed and/or JWE encrypted so that the integrity, source > authentication and confidentiality property of the Authorization > Request is attained. The request can be sent by value or by > reference. > > > > > The file can be obtained viahttps://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > > IESG discussion can be tracked viahttps://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > The document contains these normative downward references. > See RFC 3967 for additional information: > rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (Informational - IETF stream) > rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream) > rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream) > Note that some of these references may already be listed in the acceptable Downref Registry. > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation --94eb2c03fb967359de0547dd2b76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Denis. Here is my proposed disposition on your comm= ents.=C2=A0

On Fri, Feb = 3, 2017 at 8:11 PM Denis <denis.ie= tf@free.fr> wrote:
=20 =20 =20
=20

Comments on I-D Action: draft-ietf-oauth-jwsreq-11.txt

=C2=A0

Two editorial comments first :

=C2=A0

1. Guidance is a mass noun, not a count noun, plural doesn't make sense. Please change "guidances" into "guidance" twi= ce in Section 11.


Accept= ed.=C2=A0
Thanks.=C2=A0

=C2=A0

2. In Section 1= 2 : Please remove my name (Denis Pinkas) from this section.


Accepted. =C2=A0

<= /u>

=C2=A0

Other comments:=

=C2=A0

= 3. Section 1.1 (from boiler plate) states: Th= e key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to= be interpreted as described in RFC 2119 [RFC2119].

There is not a single other occurrence of the word SHALL within this document. In such case, I wonder how this document can be normative.
There are however many (useful) "non-normative examples. A non-normative example does not replace requirements.

Noted.=C2=A0
There are bunch of MUST. A= t IETF we usually prefer MUST to SHALL, unlike in ISO. =C2=A0

=C2=A0

Section 4 state= s:

=C2=A0

=C2=A0=C2=A0 A Request Object (Section 2.1) is used to provide authorization

=C2=A0=C2=A0 request parameters for an OAuth 2.0 authorization request.=C2= =A0 It

=C2=A0=C2=A0 contains OAuth 2.0 [RFC6749] authorization request parameters

=C2=A0=C2=A0 i= ncluding extension parameters.=C2=A0

=C2=A0

RFC 6749 contains 75 pages, but does not contain a single occurrence of the wording "authorization request parameter" nor of "extension parameter".
There should be either references to one or more specific sections of this document or, even better, a list of the mandatory/recommended/possible
authorization request parameters as well as a list of mandatory/recommended/possible extension parameters should be included in this document.


A clear distinction should be made between the parameters used to authenticate the request and the other ones.


Reject.=C2=A0
There are 4 flows in RFC6749. In = each flow, there is a sub-section dedicated to the Authorization request.= =C2=A0
In them, the parameters used in the authorization request = are very clearly indicated. For example,=C2=A0

4.1.1. Authorization Request

 The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI ... =

It is very difficult to miss.
=

Then, the possibility for the extension parameters are = discussed in 8.2. Needless to say, those extension parameters are going to = be discussed in other specifications.=C2=A0
Thus, it would be mis= leading just to say the parameters defined in 4.1.1, 4.2.1, etc.=C2=A0
As an editor, I feel better with the current language because it is a= t least not wrong nor misleading.=C2=A0
=C2=A0

=C2=A0

4. The introduction states on page 4:

=C2=A0<= /u>

=C2=A0=C2=A0=C2=A0=C2=A0 (a) (integrity pr= otection) The request can be signed so that the integrity of the request can be checked ;

=C2=A0

This should be changed into:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 (a) (integrity pr= otection) The request can be authenticated either using a digital signature or using encryption under a secret key
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 so that th= e integrity of the request can be checked ;


Reject.=C2=A0
This paragraph is talking ab= out the integrity protection and not the source authentication.=C2=A0
=
And even for source authentication, saying that encryption under a sec= ret key is not accurate as it was discussed earlier in the WG mail.=C2=A0

I am not sure if "Introduction" nee= ds to state everything that is explained later. The idea of introduction pr= obably is to give main points. The list is not an exhaustive list of the be= nefit of using JWT as the authorization request format. For example, being = able to encrypt the request, which is not listed there, has an advantage of= preventing MITB to eavesdrop the request. So I think it is ok as is.=C2=A0=

=C2=A0

=C2=A0=C2=A0

5. The introduction states on page 4:

=C2=A0

(d) (collection minimization) The request can be signed by a third p= arty attesting that the authorization request is compliant to certain policy.

= The request is not signed by a third party.

=

However, later on, there is the following explanation:

=C2=A0

=C2=A0=C2=A0 In addition, it allows requests to be prepared by a third party so that a client application cannot request
=C2=A0=C2=A0 more permissions than previously agreed.=C2=A0

=C2=A0

If it is the intent, the sentence should be rephrased as:

=C2=A0=

(d) (collection minimization) The request can be verified by a third= party attesting that the authorization request is compliant to certain policy.

=C2=A0

Reject
=
The third party indeed signs the request on behalf of the client as th= e result of verification that the permission is the same as previously agre= ed. =C2=A0

=C2=A0

6. Section 10.1. the text states:

=C2=A0

=C2=A0=C2=A0 When sending the authorization request object through "request"

=C2=A0=C2=A0 parameter, it MUST either be signed using JWS [RFC7515] or encrypted

=C2=A0=C2=A0 using JWE [RFC7516] with then considered appropriate algorithm.

=C2=A0

The wording" wit= h then considered appropriate algorithm" is too vague. This should be changed into:

=C2=A0

=C2=A0=C2=A0 When sending the authorization request object through "request"

=C2=A0=C2=A0 parameter, it MUST either be signed using JWS [RFC7515] or encrypted

=C2=A0=C2=A0 using JWE [RFC7516] using a symmetric key algorithm.

=C2=A0

Reject.=C2= =A0
In the above sentence, "with then considered appropriate algorithm<= /span>" =C2=A0applies both on JWS and JWE.=C2=A0
The int= ent of the phrase is that a vulnerable algorithm should not be used.=C2=A0<= /div>

Also, I do not understand why the algorithm has to= be symmetric key algorithm.=C2=A0

=C2=A0

7. Section 10.2 states:

=C2=A0

=C2=A0=C2=A0 This means that the request object is going to be prepare= d fresh each

=C2=A0=C2=A0 time an authorization request is made and caching cannot be used.=C2=A0

=C2=A0

What are the implications ? Is it required/recommended to use a nonce ? The text should be made clearer. <= /u>

Reject.=C2=A0
The implication is given right after the sentence. There is no variab= le called "nonce" in RFC6749. Since this document is just definin= g another encoding method for OAuth 2.0 authorization request as a framewor= k, it does not mandate these. An extension specification should define thos= e requirements.=C2=A0

=C2=A0<= u class=3D"gmail_msg">

8. Section 10.3 states:

=C2=A0

10.3.=C2=A0 Request Source Authentication<= /u>

=C2=A0

=C2=A0=C2=A0 The source of the Authorization Request MUST always be verified.

=C2=A0=C2=A0 There are several ways to do it in this specification.<= /u>

=C2=A0

=C2=A0=C2=A0 (a)=C2=A0 Verifying the JWS Signature of the Request Object.

=C2=A0

It seems that the case of using a JWE encrypted using a secret key algorithm has been forgotten here. Please add it.

Accepted with modification.=C2=A0
You mean, symmetric key a= lgorithm, is that right? I would add "or verifying that the symmetric = key for the=C2=A0JWE encryption is a co= rrect one"=C2=A0

=C2=A0

9. Section 10.3 states at its very end:

=C2=A0

=C2=A0=C2=A0 An extension specification <= /u>

=C2=A0=C2=A0 should be created as a preventive measure to address potential

=C2=A0=C2=A0 vulnerabilities that have not yet been identified.=

=C2=A0

Writing a document for vulnerabilities that have not yet been identified is speculative. It would rather be better
either to remove this sentence or to explain what is meant by it.

Reject.=C2=A0
It is referring to the first paragraph of the sub-section. Also, prec= aution when security is in question is a good thing.=C2=A0=C2=A0

10. Section 11.1 states:

=C2=A0

11.1.=C2=A0 Collection limitation

=C2=A0

=C2=A0=C2=A0 When the Client is being granted access to a protected resource

=C2=A0=C2=A0 containing personal data, the Client SHOULD limit the collection of

=C2=A0=C2=A0 personal data to that which is within the bounds of applicable law

=C2=A0=C2=A0 and strictly necessary for the specified purpose(s).<= /p>

=C2=A0

The presentation of personal data should be limited whether or not the protected resource contains personal data.=C2=A0

=


It is proposed to change this text into:

=C2=A0

=C2=A0=C2=A0 When the Client requests an access to a protected resource, the Client

=C2=A0=C2=A0 SHOULD limit the presentation of personal data to that which is within

=C2=A0=C2=A0 the bounds of applicable law and strictly necessary for the specified

=C2=A0=C2=A0 purpose(s).

<= div>Reject.=C2=A0
You are not getting what OAuth does. The party = that holds personal data is the authorization server / resource.=C2=A0
It is not the client. The client is the party who is getting those &q= uot;resources" which may contain personal data.=C2=A0
Yes, t= he client can provide some personal data to the resource depending on what = that resource endpoint is, but that is out of scope for OAuth.=C2=A0
<= div>As far as OAuth is concerned, what is being sent from the client to the= resource is the access token.=C2=A0

=C2=A0

11. Section 11.2.1 states:<= /u>

=C2=A0

11.2.1.=C2=A0 Request Disclosure=

=C2=A0

=C2=A0=C2=A0 This specification allows extension parameters.

=C2=A0

It would be useful to name either all of them or some of them. RFC 6749 is not crystal clear about this.

=
Noted.=C2=A0
RFC6749 only defines how to define extension pa= rameters.=C2=A0
This specification draws from OpenID Connect for = some examples of extension parameters such as nonce.=C2=A0
See se= ction 4 for example. =C2=A0

<= u class=3D"gmail_msg">

=C2=A0


Denis Pinkas (DP Security Consulting SAS)

=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=20 =20 =20 =20 =20 


The IESG has received a request from the Web=
 Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization
   Request (JAR)'
  <draft-ietf-oauth-jwsreq-11.txt> 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 2017-02-13. 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


   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be JWS
   signed and/or JWE encrypted so that the integrity, source
   authentication and confidentiality property of the Authorization
   Request is attained.  The request can be sent by value or by
   reference.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:=20
    rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (I=
nformational - IETF stream)
    rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informatio=
nal - IETF stream)
    rfc6973: Privacy Considerations for Internet Protocols (Informational -=
 IAB stream)
Note that some of these references may already be listed in the acceptable =
Downref Registry.


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


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

Nat Sakimura

Chairman of the Board, OpenID Foundation

--94eb2c03fb967359de0547dd2b76-- From nobody Mon Feb 6 06:14:41 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC69A129DA3; Mon, 6 Feb 2017 06:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9ULawRVM7Xc; Mon, 6 Feb 2017 06:14:34 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3EA1129D9A; Mon, 6 Feb 2017 06:14:33 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id b65so122241168wmf.0; Mon, 06 Feb 2017 06:14:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iqBblcxBJpi94r0QkcVPXBz5Ak3RnGNdiseim23l63Y=; b=Z4qk0H28s5x8/cN2gCOX44yygp7owC4OexSZsEoBArWKs3RhFD1Gw6mWEdcibR2SpT r94lCuL1OWezUxOzv6Z47p6LLK9GKe/yZlEAuHSAMfq0yDFH25gVp5sCZtG/Yb/xo6QZ JScaGEhDnnzDFec7Ag8aN/VJvD797L81OsNKRV/nRzbrvc6GZo8belSbdauQhnRenvUh VPMRIXhL4gyLOiAunGkQ2UuBh+4oCC7kh/Gm2ASkBARODWLqaRUlKVHmFp4la3/+epvD a6yE5tnjtKmahIXokC8N0UqMdtWcTxxFPBg5B0YVg0PqgJ80XEhcT1eOaE2Gy0Sm6nex 16hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iqBblcxBJpi94r0QkcVPXBz5Ak3RnGNdiseim23l63Y=; b=iejT9xN/M+KOr9LvdafiOXyGTX734BA406hRbLqy2Hcohw0pZrzi7pjpoyA2bTZyVM R9O7ff6oaqWl1SOwjda/cwkZEzyQNjywtgyUHKgy8lPxOA5cb6nEm9OCCXK3kGcbICPL HZPm1cZDH3QMpRWFUWrInDP8NP2qUaTaDk7ta+XtaU9GAZHZ1QnA2/CUTHLYpBMnD5iA /6/Sq+6IyVqmXtM4PQLlxvYn+guRvAFUSAVQS+1/N07FNSVPsxfS0GHTViG7jz/EOqjv 1D5aI5YA7do+5DURY5estCDBt/+QKLFpumo0QdVfaiDtXPgHt7CuBBX2ZqpuWYupCgWl 88wA== X-Gm-Message-State: AMke39kvq8OKJYdiF24k5eIH2AwAj4GRUEeELVJTxWA9HLJ2sEtzx7MmN1p2Vsqiem4N6rj639Cq8XdmuFCDmQ== X-Received: by 10.28.1.216 with SMTP id 207mr9593070wmb.7.1486390472437; Mon, 06 Feb 2017 06:14:32 -0800 (PST) MIME-Version: 1.0 References: <148607662042.13885.2832003093930390561.idtracker@ietfa.amsl.com> In-Reply-To: <148607662042.13885.2832003093930390561.idtracker@ietfa.amsl.com> From: Nat Sakimura Date: Mon, 06 Feb 2017 14:14:22 +0000 Message-ID: To: Joel Halpern , gen-art@ietf.org Content-Type: multipart/alternative; boundary=001a113c73f81b78bd0547dd4018 Archived-At: Cc: ietf@ietf.org, draft-ietf-oauth-jwsreq.all@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-11 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 14:14:36 -0000 --001a113c73f81b78bd0547dd4018 Content-Type: text/plain; charset=UTF-8 Thanks Joel, -11 only contains the fixes to the comments received by Jan. 17. I am now applying all the edits needed for the comments received after that. The next version will fix the problem you have pointed out. Best, Nat On Fri, Feb 3, 2017 at 8:03 AM Joel Halpern wrote: > Reviewer: Joel Halpern > Review result: Not Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-oauth-jwsreq-?? > Reviewer: Joel Halpern > Review Date: 2017-02-02 > IETF LC End Date: 2017-02-13 > IESG Telechat date: 2017-02-16 > > Summary: This document is ready for publication as a Proposed > Standard > > Major issues: N/A > > Minor issues: > Why is the example if section 4 (and others later on) described > as > "non-normative"? Is it incomplete? incorrect? An example is, by > definition, not a full specification. The language seems designed to > reduce the value of the example. I would recommend removing all the > "non-normative" notes from the examples. They are clearly stated to > be examples. > > Nits/editorial comments: > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Nat Sakimura Chairman of the Board, OpenID Foundation --001a113c73f81b78bd0547dd4018 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Joel,=C2=A0

-11 only contains th= e fixes to the comments received by Jan. 17. I am now applying all the edit= s needed for the comments received after that.=C2=A0
The next ver= sion will fix the problem you have pointed out.=C2=A0

<= div>Best,=C2=A0

Nat

On Fri, Feb 3, 2017 at 8:03 AM Joel Halpern &l= t;jmh@joelhalpern.com> wrote:=
Reviewer: Joel Halpern
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/= wiki/GenArtfaq>.

Document: draft-ietf-oauth-jwsreq-??
Reviewer: Joel Halpern
Review Date: 2017-02-02
IETF LC End Date: 2017-02-13
IESG Telechat date: 2017-02-16

Summary: This document is ready for publication as a Proposed
Standard

Major issues: N/A

Minor issues:
=C2=A0 =C2=A0 Why is the example if section 4 (and others later on) describ= ed
as
"non-normative"?=C2=A0 Is it incomplete?=C2=A0 incorrect?=C2=A0 A= n example is, by
definition, not a full specification.=C2=A0 The language seems designed to<= br class=3D"gmail_msg"> reduce the value of the example.=C2=A0 I would recommend removing all the "non-normative" notes from the examples.=C2=A0 They are clearly s= tated to
be examples.

Nits/editorial comments:


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

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a113c73f81b78bd0547dd4018-- From nobody Mon Feb 6 07:27:40 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339CB129E7B for ; Mon, 6 Feb 2017 07:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-xeDVSXqwsK for ; Mon, 6 Feb 2017 07:27:37 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 E02C2129E76 for ; Mon, 6 Feb 2017 07:27:36 -0800 (PST) X-AuditID: 1209190e-1fbff70000001def-79-589895e6a410 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 99.E9.07663.6E598985; Mon, 6 Feb 2017 10:27:34 -0500 (EST) 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 v16FRXhM021357; Mon, 6 Feb 2017 10:27:34 -0500 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 v16FRWDW018932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Feb 2017 10:27:33 -0500 From: Justin Richer Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0BCDBF14-0F76-48B5-A8AA-8D10BA09BE12" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 6 Feb 2017 10:27:31 -0500 In-Reply-To: <0a8ab2ad-9f14-6915-464f-119a724422c7@free.fr> To: Denis References: <541A5105-B963-4FA4-94E4-D794A73B3358@ve7jtb.com> <14c5b7d3-9faa-0e2f-1411-689ab13d4fad@manicode.com> <0a8ab2ad-9f14-6915-464f-119a724422c7@free.fr> X-Mailer: Apple Mail (2.3259) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixG6novts6owIg45nRhbru+wsTr59xebA 5NG/7jOrx5IlP5kCmKK4bFJSczLLUov07RK4Mo6vnsZS8GMLY8WiXb9YGxhfL2DsYuTkkBAw kbh65At7FyMXh5BAG5PEgXcHoZwNjBJ/N61ghXAeMEkcnPuaDaSFTUBVYvqaFiYQm1fASmL9 j/1ANgcHs0CSxJFHyRBhfYnZZy6xgNjCAg4S826eZAexWQRUJF4vWQG2mVPAWmLTiQ52iFZ1 ifaTLiBhEQE5iVX3rjFDrF3FLNF7ai0rxKWyEm9/LWGewMg/C2HbLCTbQGxmAW2JZQtfM0PY mhL7u5djEdeQ6Pw2kXUBI9sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXWO93MwSvdSU0k2MoMDm lOTbwTipwfsQowAHoxIPb0bHjAgh1sSy4srcQ4ySHExKoryGHlMjhPiS8lMqMxKLM+KLSnNS iw8xSnAwK4nwLpwEVM6bklhZlVqUD5OS5mBREucV12iMEBJITyxJzU5NLUgtgsnKcHAoSfA6 AyNYSLAoNT21Ii0zpwQhzcTBCTKcB2j4kSkgw4sLEnOLM9Mh8qcYdTmmTL34kkmIJS8/L1VK nPf/ZKAiAZCijNI8uDmghJTw9rDpK0ZxoLeEeTeCjOIBJjO4Sa+AljABLdl2ZRrIkpJEhJRU A6Pzl7JJq7OimF9aVH+9f3nW/YP+B7J/vTtkvk/tsq9dKe+vPZ1burbX3TaILtv1mLE8K+KQ v8DhuO4drhV17lb2bNrdi/8q79v80isnYcP2B/v03y+ZMpH/3PX45Zfdo66E+39hN1p+78hP dRXLlC1SH3sZ1z49W7TgnORH/juvpAv/erz9tFRZiaU4I9FQi7moOBEACIWxVyMDAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 15:27:39 -0000 --Apple-Mail=_0BCDBF14-0F76-48B5-A8AA-8D10BA09BE12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OpenID Connect is the intellectual property of the OpenID Foundation and = it is discussed there. =E2=80=94 Justin > On Feb 6, 2017, at 7:30 AM, Denis wrote: >=20 >=20 > The scope of this draft is unclear. The title states: "OAuth Security = Topics". > I have some questions: > Does this document intend to cover only the OAuth 2.0 delegation = protocol (since Justin said that OAuth 2.0 is a delegation protocol)=20 > or OpenId Connect as well which is not limited to a delegation = protocol ? > Should we discuss OpenID Connect issues and/or solutions in an IETF = RFC ? > If this document is going to be progressed, the threats should be = clearly separated whether they relate to a delegation model or to=20 > a client-server access control model. This is not currently the case. > If this document is going to be progressed, the ABC attack (in the = context of an access control model) should be mentioned even if there = exits=20 > no way to counter it given the current implicit assumptions made in = OAuth 2.0, in particular the use of software only implementations. >=20 > Denis >=20 >> A belated +1 >>=20 >>=20 >> On Sat, Feb 4, 2017, 9:08 AM Jim Manico > wrote: >> I'm just some random idiot am an not in this working group but the = work from = https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 = = is one of the most up to date and useful OAuth security resources every = published. I am thrilled to see more work put into it. >>=20 >> Aloha, Jim >>=20 >>=20 >> On 2/3/17 1:57 PM, William Denniss wrote: >>> I support the adoption of this document as a working group item. >>>=20 >>> On Thu, Feb 2, 2017 at 2:30 PM, Jim Willeke > wrote: >>> +!=20 >>> I agree this is needed. >>>=20 >>> -- >>> -jim >>> Jim Willeke >>>=20 >>> On Thu, Feb 2, 2017 at 4:33 PM, John Bradley > wrote: >>> I am in favour of adoption. >>> > On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig = > wrote: >>> > >>> > Hi all, >>> > >>> > this is the call for adoption of the 'OAuth Security Topics' = document >>> > following the positive call for adoption at the last IETF >>> > meeting in Seoul. >>> > >>> > Here is the document: >>> > = https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00 = >>> > >>> > The intention with this document is to have a place to collect >>> > discussions and conclusions around OAuth 2.0 security and to = reference >>> > the actual solution specifications. >>> > >>> > Please let us know by Feb 16th whether you accept / object to the >>> > adoption of this document as a starting point for work in the = OAuth >>> > working group. >>> > >>> > Ciao >>> > Hannes & Derek >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> --=20 >> Jim Manico >> Manicode Security >> https://www.manicode.com = _______________________________________________= >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> --=20 >> Nat Sakimura >>=20 >> Chairman of the Board, OpenID Foundation >>=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 = --Apple-Mail=_0BCDBF14-0F76-48B5-A8AA-8D10BA09BE12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 OpenID Connect is the intellectual property of the OpenID = Foundation and it is discussed there.

 =E2=80=94 Justin

On Feb 6, 2017, at 7:30 AM, Denis <denis.ietf@free.fr> = wrote:


The scope of this = draft is unclear. The title states: "OAuth Security Topics".

I have some questions:

  • Does this document intend to = cover only the OAuth 2.0 delegation protocol (since Justin said that = OAuth 2.0 is a delegation protocol) 
    or OpenId = Connect as well which is not limited to a delegation protocol ?
  • Should we discuss OpenID Connect issues and/or solutions in = an IETF RFC ?

If this document is going to be progressed, the threats = should be clearly separated whether they relate to a delegation model or = to 
a = client-server access control model. This is not currently the case.

If this document = is going to be progressed, the ABC attack (in the context of an access = control model) should be mentioned even if there exits 
no way to = counter it given the current implicit assumptions made in OAuth 2.0, in = particular the use of software only implementations.


Denis

A belated +1


On Sat, Feb 4, 2017, = 9:08 AM Jim Manico <jim@manicode.com> = wrote:

I'm just some random idiot am = an not in this working group but the work from https://tools.ietf.org/html/draft-lodderstedt-oauth-secu= rity-topics-00 is = one of the most up to date and useful OAuth security resources every = published. I am thrilled to see more work put into it.

Aloha, Jim


On 2/3/17 1:57 PM, William Denniss wrote:
I support the = adoption of this document as a working group item.

On Thu, Feb 2, 2017 at 2:30 PM, Jim = Willeke <jim@willeke.com> wrote:
+! 
I agree this is needed.

--
-jim
Jim = Willeke

On Thu, Feb 2, 2017 at 4:33 PM, John = Bradley <ve7jtb@ve7jtb.com> wrote:
I am in favour of adoption.
> On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> = wrote:
>
> Hi = all,
>
> this is the = call for adoption of the 'OAuth Security Topics' document
> following the positive call for adoption at the = last IETF
> meeting in Seoul.
>
> Here is the = document:
> https://tools.ietf.org/html/draft-lodderstedt-oauth-secu= rity-topics-00
>
>= The intention with this document is to have a place to collect
> discussions and conclusions around OAuth 2.0 = security and to reference
> the actual = solution specifications.
>
> Please let us know by Feb 16th whether you = accept / object to the
> adoption of this = document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & = Derek
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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



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




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


--=20
Jim Manico
Manicode Security
https://www.manicode.com
________________= _______________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
-- 

Nat Sakimura

Chairman of the = Board, OpenID Foundation



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


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

= --Apple-Mail=_0BCDBF14-0F76-48B5-A8AA-8D10BA09BE12-- From nobody Thu Feb 9 13:15:31 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8A2129484; Thu, 9 Feb 2017 13:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E386ZIYNrCB2; Thu, 9 Feb 2017 13:15:19 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 0B109126D74; Thu, 9 Feb 2017 13:15:19 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 07567780310; Thu, 9 Feb 2017 22:15:14 +0100 (CET) To: Nat Sakimura , ietf@ietf.org, IETF-Announce References: <148581788158.29828.4591033587037530374.idtracker@ietfa.amsl.com> <3a6b8cee-ff29-323e-9042-5df6e71a8d81@free.fr> From: Denis Message-ID: <81f50f3f-2f04-c74a-d47a-dad8cd9f715a@free.fr> Date: Thu, 9 Feb 2017 22:15:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------69CBEBA95C3BE4C4C2BE2340" Archived-At: Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 21:15:25 -0000 This is a multi-part message in MIME format. --------------69CBEBA95C3BE4C4C2BE2340 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Nat, My replies to your proposed disposition of comments are embedded in the text. > Thanks Denis. Here is my proposed disposition on your comments. > > On Fri, Feb 3, 2017 at 8:11 PM Denis > wrote: > > *Comments on I-D Action: draft-ietf-oauth-jwsreq-11.txt* > > Two editorial comments first : > > 1. Guidance is a mass noun, not a count noun, plural doesn't make > sense. > Please change "guidances" into "guidance" twice in Section 11. > > Accepted. > Thanks. > > 2. In Section 12 : Please remove my name (Denis Pinkas) from this > section. > > Accepted. > > Other comments: > > 3. Section 1.1 (from boiler plate) states: The key words "MUST", > "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", > "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > > There is not a single other occurrence of the word SHALL within > this document. In such case, I wonder how this document can be > normative. > There are however many (useful) "non-normative examples. A > non-normative example does not replace requirements. > > Noted. > There are bunch of MUST. At IETF we usually prefer MUST to SHALL, > unlike in ISO. OK. > > Section 4 states: > > *A Request Object (Section 2.1) is used to provide authorization > request parameters for an OAuth 2.0 authorization request.It > contains OAuth 2.0 [RFC6749] authorization request parameters > including extension parameters**.* > > RFC 6749 contains 75 pages, but does not contain a single > occurrence of the wording "authorization request parameter" nor of > "extension parameter". > There should be either references to one or more specific sections > of this document or, even better, a list of the > mandatory/recommended/possible > authorization request parameters as well as a list of > mandatory/recommended/possible extension parameters should be > included in this document. > > A clear distinction should be made between the parameters used to > authenticate the request and the other ones. > > > Reject. > There are 4 flows in RFC6749. In each flow, there is a sub-section > dedicated to the Authorization request. > In them, the parameters used in the authorization request are very > clearly indicated. For example, > > > 4.1.1 . > Authorization Request > > > > The client constructs the request URI by adding the following > parameters to the query component of the authorization endpoint URI ... > It is very difficult to miss. > > Then, the possibility for the extension parameters are discussed in > 8.2. Needless to say, those extension parameters are going to be > discussed in other specifications. > Thus, it would be misleading just to say the parameters defined in > 4.1.1, 4.2.1, etc. > As an editor, I feel better with the current language because it is at > least not wrong nor misleading. draft-ietf-oauth-jwsreq-11states on page 7. To sign, JSON Web Signature (JWS) [RFC7515] is used.The result is a JWS signed JWT [RFC7519].If signed, the Authorization Request Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience) as members, with their semantics being the same as defined in the JWT [RFC7519] specification. This should be changed into: To sign, JSON Web Signature (JWS) [RFC7515] is used.The result is a JWS signed JWT [RFC7519].If signed, the Authorization Request Object *MUST contain a client_id parameter* and SHOULD contain a "iss" (issuer) *parameter* and an "aud" (audience) *parameter*, with their semantics being the same as defined in the JWT RFC7519] specification. In section 5.2. Message Signature or MAC Validation, the text states: When validating a JWS, the following steps are performed. (...) See Section 10.6 for security considerations on algorithm validation. There is no section 10.6 in this document. It seems to be section 10.3 Anyway, it is not the right place to place requirements in a security considerations section and the appropriate text should be moved in the main body of the document. RFC 6749 states in clause 4.Obtaining Authorization on page 6.2.JWS Signed Request Object To perform JWS Signature Validation, the "alg" Header Parameter in the JOSE Header MUST match the value of the pre-registered algorithm. The signature MUST be validated against the appropriate key for that "client_id" and algorithm. The important point is to provide guidance on how to map the client_idparameter with the appropriate key. There is none at the present time. Add: Identifying the appropriate key MUST be done according to section 6 of RFC 7515 and using the Registered Header Parameter Names defined in section 4.1 of RFC 7515, e.g. using the Header Parameters "jku", "jwk", "kid", "x5u", "x5c", "x5t", or "x5t#S256". > 4. The introduction states on page 4: > > (a) (integrity protection) The request can be signed so that > the integrity of the request can be checked; > > This should be changed into: > > (a) (integrity protection) The request can be authenticated > either using a digital signature or using encryption under a > secret key > so that the integrity of the request can be checked; > > > Reject. > This paragraph is talking about the integrity protection and not the > source authentication. > And even for source authentication, saying that encryption under a > secret key is not accurate as it was discussed earlier in the WG mail. > > I am not sure if "Introduction" needs to state everything that is > explained later. The idea of introduction probably is to give main > points. The list is not an exhaustive list of the benefit of using JWT > as the authorization request format. For example, being able to > encrypt the request, which is not listed there, has an advantage of > preventing MITB to eavesdrop the request. So I think it is ok as is. > Integrity protection cannot be verified without knowing the source of the information. Using encryption (which supports at the same time an integrity service when secret keys are being used) is another way to be able to check the integrity of the request. So I maintain may comment. > 5. The introduction states on page 4: > > (d) (collection minimization) The request can be *signed* by a > third party attesting that the authorization request is compliant > tocertain policy. > > The request is not /signed/ by a third party. > > However, later on, there is the following explanation: > > In addition, it allows requests to be prepared by a third party so > that a client application cannot request > more permissions than previously agreed. > > If it is the intent, the sentence should be rephrased as: > > (d) (collection minimization) The request can be *verified* by a > third party attesting that the authorization request is compliant > tocertain policy. > > Reject > The third party indeed signs the request on behalf of the client as > the result of verification that the permission is the same as > previously agreed. If it were the case, the client_id would indicate the name of the third party and the name of the user would be missing (or vice versa). So I maintain my comment. > 6. Section 10.1. the text states: > > *When sending the authorization request object through "request" > parameter, it MUST either be signed using JWS [RFC7515] or encrypted > using JWE [RFC7516] with then considered appropriate algorithm.* > > The wording"with then considered appropriate algorithm"is too > vague. This should be changed into: > > *When sending the authorization request object through "request" > parameter, it MUST either be signed using JWS [RFC7515] or encrypted > using JWE [RFC7516] using a symmetric key algorithm.* > > Reject. > > In the above sentence, "*with then considered appropriate algorithm*" > applies both on JWS and JWE. > The intent of the phrase is that a vulnerable algorithm should not be > used. > > Also, I do not understand why the algorithm has to be symmetric key > algorithm. Maybe, this explains why you didn't understand the previous comment. With public key encryption, it is not possible to authenticate the source of the request, while it is possible with secret key encryption when the encrypted data includes a cryptographic checksum like a hash value and an error propagation method for the encryption algorithm. So I maintain my comment. > 7. Section 10.2 states: > > This means that the request object is going to be prepared fresh each > time an authorization request is madeand caching cannot be used. > > What are the implications ? Is it required/recommended to use a > nonce ? The text should be made clearer. > > Reject. > The implication is given right after the sentence. There is no > variable called "nonce" in RFC6749. Since this document is just defining > another encoding method for OAuth 2.0 authorization request as a > framework, it does not mandate these. > An extension specification should define those requirements. Note that this section belongs to the security considerations section which SHOULD NOT be normative and should only provide guidance. The sentence right after is the following: It has a performance disadvantage, but where such disadvantage is permissible, it should be considered. It does not provide any guidance. The key point is that a parameter able to detect replay needs to be included in the request. This should be indicated in the normative part. It is unfortunate that RFC 7515 has not addressed replay protection of JWS and only mentions the problem is section 10.10 which is in the security considerations section. Here it is: 10.10.Replay Protection While not directly in scope for this specification, note that applications using JWS (or JWE) objects can thwart replay attacks by including a unique message identifier as integrity-protected content in the JWS (or JWE) message and having the recipient verify that the message has not been previously received or acted upon. The text on page 7 should be changed into: To sign, JSON Web Signature (JWS) [RFC7515] is used.The result is a JWS signed JWT [RFC7519].If signed, the Authorization Request Object *MUST contain a client_id parameter* *and a "nonce"* *extension **parameter* *allowing to detect replay attacks *and SHOULD contain an "iss" (issuer) *parameter* and an "aud" (audience) *parameter*, with their semantics being the same as defined in the JWT specification[RFC7519]. Note that Page 7 uses the "nonce" parameter in the example. JSON Web Token Claims are listed at: https://www.iana.org/assignments/jwt/jwt.xhtml "Nonce" is mentioned in OpenID Connect Core 1.0 incorporating errata set 1. It is described as : nonce Value used to associate a Client session with an ID Token This is too restrictive since now a nonce should be included in a JWS token. The registration is as follows: * Parameter name: nonce * Parameter usage location: Authorization Request * Change controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net * Specification document(s): Section 3.1.2 of this document * Related information: None Section 3.1.2 states: 3.1.2. Authorization Endpoint The Authorization Endpoint performs Authentication of the End-User. This is done by sending the User Agent to the Authorization Server's Authorization Endpoint for Authentication and Authorization, using request parameters defined by OAuth 2.0 and additional parameters and parameter values defined by OpenID Connect. Communication with the Authorization Endpoint MUST utilize TLS. See Section 16.17 for more information on using TLS This has nothing to do with the nonce. Hence the nonce registration information has been badly defined. The OpenID specification also states: "The Client SHOULD check the noncevalue for replay attacks. The precise method for detecting replay attacks is Client specific". This does not allow to interoperate. Rather than correcting the registration information in the OpenID specification, it would be better to suppress it from the OpenID specification and incorporate it within an IETF RFC. In order to avoid nonces to be kept in a memory for ever, a good practice is to split the nonce in two parts: * one of them includes a UTC NumericDate using the format defined in RFC 7519,and * the other one includes a random number. In this way only recent nonces (e.g. received during the last 5 minutes) need to be kept in memory. Three or fourbytes for the random number will be sufficient. In order to *allow for interoperability,* a format should be specified. I propose a NumericDate defining the UTC time concatenated with a random number with three bytes. "Nonce" has not been officially registered by IANA. An IANA Considerations section should be added in draft-ietf-oauth-jwsreq-* *to register the "nonce" parameter. On page 14, section 6.2., after the previous proposed text which is: Identifying the appropriate key MUST be done according to section 6 of RFC 7515 and using the Registered Header Parameter Names defined in section 4.1 of RFC 7515, e.g. using the Header Parameters "jku", "jwk", "kid", "x5u", "x5c", "x5t", or "x5t#S256". I proposed to add the following text: To perform JWS Signature Validation, the "nonce" Header Parameter in the JOSE Header MUST be present and MUST be checked to verify that the signed request is not the replay of a previous signed request. A section defining the nonce parameter should be added. > 8. Section 10.3 states: > > 10.3.Request Source Authentication > > The source of the Authorization Request MUST always be verified. > > There are several ways to do it in this specification. > > (a)Verifying the JWS Signature of the Request Object. > > It seems that the case of using a JWE encrypted using a secret > key algorithm has been forgotten here. Please add it. > > Accepted with modification. > You mean, symmetric key algorithm, is that right? I would add "or > verifying that the symmetric key for theJWE encryption is a correct one" Accepted > 9. Section 10.3 states at its very end: > > An extension specification > should be created as a preventive measure to address potential > vulnerabilities that have not yet been identified. > > > Writing a document for vulnerabilities that have not yet been > identified is speculative. It would rather be better > either to remove this sentence or to explain what is meant by it. > > Reject. > It is referring to the first paragraph of the sub-section. Also, > precaution when security is in question is a good thing. This sentence is simply useless and thus should be deleted. Hence, I maintain this comment. > 10. Section 11.1 states: > > *11.1.Collection limitation* > > *When the Client is being granted access to a protected resource > containing personal data, the Client SHOULD limit the collection of > personal data to that which is within the bounds of applicable law > and strictly necessary for the specified purpose(s).*** > > The /presentation/ of personal data should be limited whether or > not the protected resource contains personal data. > > It is proposed to change this text into: > > *When the Client requests an access to a protected resource, the > Client > SHOULD limit the presentation of personal data to that which is within > the bounds of applicable law and strictly necessary for the specified > purpose(s).* > > Reject. > You are not getting what OAuth does. The party that holds personal > data is the authorization server / resource. > It is not the client. The client is the party who is getting those > "resources" which may contain personal data. > Yes, the client can provide some personal data to the resource > depending on what that resource endpoint is, but that is out of scope > for OAuth. > As far as OAuth is concerned, what is being sent from the client to > the resource is the access token. The dispute is whether the protected resource contains or not personal data. The data contained by the protected resource may well be public data (or/and personal data). It does not need to be only "personal data". Hence, I maintain my comment. > ** > > 11. Section 11.2.1 states: > > 11.2.1.Request Disclosure > > This specification allows extension parameters. > > It would be useful to name either all of them or some of them. > RFC 6749 is not crystal clear about this. > > Noted. > RFC6749 only defines how to define extension parameters. > This specification draws from OpenID Connect for some examples of > extension parameters such as nonce. > See section 4 for example. See my earlier comments where client_id and nonce shall be mandatory. Denis > > Denis Pinkas (DP Security Consulting SAS) > > ============================================================== > >> The IESG has received a request from the Web Authorization Protocol WG >> (oauth) to consider the following document: >> - 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization >> Request (JAR)' >> 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 2017-02-13. Exceptionally, comments may be >> sent toiesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> The authorization request in OAuth 2.0 described in RFC 6749 utilizes >> query parameter serialization, which means that Authorization Request >> parameters are encoded in the URI of the request and sent through >> user agents such as web browsers. While it is easy to implement, it >> means that (a) the communication through the user agents are not >> integrity protected and thus the parameters can be tainted, and (b) >> the source of the communication is not authenticated. Because of >> these weaknesses, several attacks to the protocol have now been put >> forward. >> >> This document introduces the ability to send request parameters in a >> JSON Web Token (JWT) instead, which allows the request to be JWS >> signed and/or JWE encrypted so that the integrity, source >> authentication and confidentiality property of the Authorization >> Request is attained. The request can be sent by value or by >> reference. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> The document contains these normative downward references. >> See RFC 3967 for additional information: >> rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (Informational - IETF stream) >> rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream) >> rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream) >> Note that some of these references may already be listed in the acceptable Downref Registry. >> >> >> _______________________________________________ >> 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 > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > --------------69CBEBA95C3BE4C4C2BE2340 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Nat,

My replies to your proposed disposition of comments are embedded in the text.

Thanks Denis. Here is my proposed disposition on your comments. 

On Fri, Feb 3, 2017 at 8:11 PM Denis <denis.ietf@free.fr> wrote:

Comments on I-D Action: draft-ietf-oauth-jwsreq-11.txt

 Two editorial comments first :

 1. Guidance is a mass noun, not a count noun, plural doesn't make sense.
Please change "guidances" into "guidance" twice in Section 11.

Accepted. 
Thanks. 

 2. In Section 12 : Please remove my name (Denis Pinkas) from this section.

Accepted.  

 Other comments:

 

3. Section 1.1 (from boiler plate) states: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

There is not a single other occurrence of the word SHALL within this document. In such case, I wonder how this document can be normative.
There are however many (useful) "non-normative examples. A non-normative example does not replace requirements.

Noted. 
There are bunch of MUST. At IETF we usually prefer MUST to SHALL, unlike in ISO.
OK.

 Section 4 states:

    A Request Object (Section 2.1) is used to provide authorization
   request parameters for an OAuth 2.0 authorization request.  It
   contains OAuth 2.0 [RFC6749] authorization request parameters
   including extension parameters. 

RFC 6749 contains 75 pages, but does not contain a single occurrence of the wording "authorization request parameter" nor of "extension parameter".
There should be either references to one or more specific sections of this document or, even better, a list of the mandatory/recommended/possible
authorization request parameters as well as a list of mandatory/recommended/possible extension parameters should be included in this document.

A clear distinction should be made between the parameters used to authenticate the request and the other ones.


Reject. 
There are 4 flows in RFC6749. In each flow, there is a sub-section dedicated to the Authorization request. 
In them, the parameters used in the authorization request are very clearly indicated. For example, 

4.1.1.  Authorization Request


   The client constructs the request URI by adding the following
   parameters to the query component of the authorization endpoint URI ... 

            It is very difficult to miss. 

          


          

          
Then, the possibility for the extension parameters are
            discussed in 8.2. Needless to say, those extension
            parameters are going to be discussed in other
            specifications. 

          
Thus, it would be misleading just to say the parameters
            defined in 4.1.1, 4.2.1, etc. 

          
As an editor, I feel better with the current language
            because it is at least not wrong nor misleading. 

          

        

      

    

    

    
    
draft-ietf-oauth-jwsreq-11
          states on page 7.

    
 

    
   To sign, JSON Web
        Signature (JWS) [RFC7515]
        is used.  The result is
        a

    
   JWS signed JWT [RFC7519].  If signed, the
        Authorization Request

    
   Object SHOULD contain the
        Claims
        "iss" (issuer) and "aud" (audience)

    
   as members, with their
        semantics being the
        same as defined in the JWT

    
   [RFC7519] specification.

    
 

    
This should be changed into:

    
 

    
   To sign, JSON Web
        Signature (JWS) [RFC7515]
        is used.  The result is
        a

    
   JWS signed JWT [RFC7519].  If signed, the
        Authorization Request

    
   Object MUST contain a
          client_id
          parameter and SHOULD contain a

           "iss" (issuer) parameter
        and an "aud" (audience) parameter, with 

           their semantics being
        the same as
        defined in the JWT RFC7519] 

           specification.

    
 

    
In section
          5.2. Message Signature or MAC Validation, the text states:

    
    
    
 

    
    
    
   When validating a JWS,
          the following steps
          are performed.

    
    
    
 

    
    
    
(...)

    
    
    
       See Section 10.6
          for security
          considerations on algorithm

    
    
    
       validation.

    
    
    
 

    
    
    
There is no
          section 10.6 in this document. It seems to be section 10.3

    
    
    
Anyway, it
          is not the right place to place requirements in a security
          considerations
          section and the appropriate text 

          should be moved in the main body of the
          document.

    
    
    
 

    
    
    
RFC 6749
          states in clause 4.  Obtaining
          Authorization on page 

    
 

    
6.2.  JWS Signed Request Object

    
 

    
   To perform JWS Signature
        Validation, the
        "alg" Header Parameter in

    
   the JOSE Header MUST match the value of the
        pre-registered
        algorithm.

    
   The signature MUST be validated against the appropriate
          key for that

    
  
        "client_id" and algorithm.

    
 

    
The
          important point is to provide guidance on how to map the client_id
          parameter with the appropriate key. 

          There
          is none at the present time.

    
    
    
 

    
    
    
Add:

    
 

    
   Identifying
        the appropriate
        key MUST be done according to section 6 

           of RFC 7515 and using
        the Registered
        Header Parameter Names defined 

           in section 4.1 of RFC
        7515, e.g.
        using the Header Parameters "jku", 

           "jwk", "kid",
        "x5u", "x5c", "x5t", or "x5t#S256".

    
 

    
    
    
    
    
    

    

      

        

          
 4. The introduction states
              on page 4:

          

            

              

                
 

                
     (a) (integrity protection) The
                    request can be signed so that the integrity of the
                    request can be checked ;
                  

                
 

                
This should be changed into:

                
 

                
     (a) (integrity protection) The
                    request can be authenticated either using a digital
                    signature or using encryption under a secret key 

                              so that the integrity of the request can
                    be checked ;

              

            

          

          


          

          
Reject. 

          

            
This paragraph is talking about the integrity
              protection and not the source authentication. 

            
And even for source authentication, saying that
              encryption under a secret key is not accurate as it was
              discussed earlier in the WG mail. 

          

          


          

          
I am not sure if "Introduction" needs to state everything
            that is explained later. The idea of introduction probably
            is to give main points. The list is not an exhaustive list
            of the benefit of using JWT as the authorization request
            format. For example, being able to encrypt the request,
            which is not listed there, has an advantage of preventing
            MITB to eavesdrop the request. So I think it is ok as is. 

          


          

        

      

    

    
    
Integrity protection cannot be verified
        without knowing the source of
        the information. Using encryption (which supports at the same
        time 

        an integrity
        service when secret keys are being used) is another way to be
        able to check the
        integrity of the request. 

    
 

    
So I maintain may comment.

    


      

    
    
    
    
    
    
    

      

        

          
 5. The introduction states on page 4:

          

            

              

                
 

                
(d) (collection minimization) The
                    request can be signed by a
                    third party attesting that the authorization request
                    is compliant to certain policy.

                
The request is not signed by a third party. 

                  

              

            

          

          

            

              

                
However, later on,
                    there is the following explanation: 

                  

                
   In addition, it
                    allows requests to be prepared by a third party so
                    that a client application cannot request 

                       more permissions than previously
                    agreed.  

                
 If it is the intent,
                    the sentence should be rephrased as: 

                  

                
(d) (collection minimization) The
                    request can be verified by
                    a third party attesting that the authorization
                    request is compliant to certain policy. 

                  

              

            

          

          
Reject

          
The third party indeed signs the request on behalf of the
            client as the result of verification that the permission is
            the same as previously agreed.  

          

        

      

    

    

    
    
If it were the case, the client_id would
        indicate the name of the third
        party and the name of the user would be missing (or vice versa).

    
                       

    
So I maintain my comment.

    

    

    

      

        

          

            

              

                

                
 6. Section 10.1. the
                    text states: 

                  

                
   When
                      sending the authorization request object through
                      "request"

                         parameter, it
                      MUST either be signed using JWS [RFC7515] or
                      encrypted

                         using JWE
                      [RFC7516] with then considered appropriate
                      algorithm.

                
 The wording" with then considered
                    appropriate algorithm" is too vague. This
                    should be changed into:

                
   When
                      sending the authorization request object through
                      "request"

                         parameter, it
                      MUST either be signed using JWS [RFC7515] or
                      encrypted

                         using JWE
                      [RFC7516] using a symmetric key
                        algorithm.

                
 Reject. 

              

            

          

          
In the above sentence, "with then considered
                appropriate algorithm"  applies both on JWS
            and JWE. 

          
The intent of the phrase is that a vulnerable algorithm
            should not be used. 

          


          

          
Also, I do not understand why the algorithm has to be
            symmetric key algorithm. 

          

        

      

    

    

    
    
Maybe, this explains why you didn't
        understand the previous comment.
        With public key encryption, it is not possible to authenticate 

        the source of
        the request, while it is possible with secret key encryption
        when the encrypted
        data includes a cryptographic checksum 

        like a hash value and an error
        propagation method for the encryption algorithm.

    
 

    
So I maintain my comment.

    

    

    

      

        

          

            

              

                

                
 7. Section 10.2
                    states: 

                  

                
   This means that the
                    request object is going to be prepared fresh each

                         time an authorization request is made and caching cannot
                    be used.  

                
 What are the
                    implications ? Is it required/recommended to use a
                    nonce ? The text should be made clearer. 

                

              

            

          

          
Reject. 

          
The implication is given right after the sentence. There
            is no variable called "nonce" in RFC6749. Since this
            document is just defining 

            another encoding method for OAuth 2.0 authorization request
            as a framework, it does not mandate these. 

            An extension specification should define those requirements.
            

          

        

      

    

    

    
    
Note that this section belongs to the
        security considerations section
        which SHOULD NOT be normative and should only provide guidance.
        

    
 

    
The sentence right after is the following:

    
 

    
   It has a performance
        disadvantage, but
        where such disadvantage is

    
   permissible, it should be
        considered.

    
 

    
It does not provide any guidance. 

    
 

    
The key point is that a parameter able to
        detect replay needs to be
        included in the request. This should be indicated in the
        normative part. 

        It is
        unfortunate that RFC 7515 has not addressed replay protection of
        JWS and only
        mentions the problem is section 10.10 which is in the 

        security considerations
        section. Here it is:

    
 

    
10.10.  Replay
        Protection

    
   While
        not directly in scope
        for this specification, note that

    
   applications
        using JWS (or
        JWE) objects can thwart replay attacks by

    
   including
        a unique message
        identifier as integrity-protected content

    
   in
        the JWS (or JWE) message
        and having the recipient verify that the

    
   message
        has not been
        previously received or acted upon.

    
 

    
The text on page 7 should be changed
        into:

    
 

    
   To sign, JSON Web
        Signature (JWS) [RFC7515]
        is used.  The result is
        a

           JWS signed JWT
        [RFC7519].  If signed,
        the Authorization Request

           Object MUST
          contain a client_id
          parameter and a "nonce" extension 

           parameter
      allowing to detect
          replay attacks and SHOULD
        contain an "iss" 

           (issuer) parameter
        and an
        "aud" (audience) parameter, with their 

           semantics being the
        same as defined
        in the JWT specification[RFC7519].

    
 

    
Note that Page 7 uses the
        "nonce" parameter in the example. 

    
JSON Web Token
        Claims are listed at: https://www.iana.org/assignments/jwt/jwt.xhtml

    
"Nonce" is mentioned in OpenID Connect Core
        1.0 incorporating
        errata set 1. 

    
 

    
It is described as :

    
 

    

      
        

          
            
nonce

          		
          
            
Value used to associate a Client session
                with an ID Token

          		
        

      
    

    


      

    
This is too restrictive since now a nonce
        should be included in a JWS
        token.

    
 

    
The registration is as follows:

    
    
      
  • Parameter
          name: nonce 
    • 
      
  • Parameter
          usage location: Authorization Request 
    • 
      
  • Change
          controller: OpenID Foundation Artifact Binding Working Group -
          openid-specs-ab@lists.openid.net 
    • 
      
  • Specification
          document(s): Section 3.1.2 of this
          document 
    • 
      
  • Related information: None 
    • 
    

    


      

    
Section 3.1.2 states:

    
3.1.2. 
        Authorization Endpoint

    
The Authorization Endpoint performs
        Authentication of the End-User. This
        is done by sending the User Agent to the Authorization Server's
        

        Authorization
        Endpoint for Authentication and Authorization, using request
        parameters defined
        by OAuth 2.0 and additional parameters 

        and parameter values defined by OpenID
        Connect. 

    
 

    
Communication with the Authorization
        Endpoint MUST utilize TLS. See Section 16.17
        for more
        information on using TLS

    
 

    
This has nothing to do with the nonce. Hence
        the nonce registration
        information has been badly defined. 

    
 

    
The OpenID specification also states:

    


      

    
 

    
"The Client
          SHOULD check the nonce value for replay
          attacks. The precise method for detecting replay
          attacks is Client specific".

    
 

    
This does not allow to interoperate.

    
 

    
Rather than correcting the registration
        information in the OpenID
        specification, it would be better to suppress it from the OpenID
        specification
        

        and incorporate it within an IETF RFC.

    
 

    
In order to avoid nonces to be kept in a
        memory for ever, a good
        practice is to split the nonce in two parts: 

      

    
    
      
  • one of them
          includes a UTC NumericDate
            using the format defined in RFC 7519, and 
    • 
      
  • the other one
          includes a random number. 
    
        
    • 
    

    


        In
        this way only recent nonces (e.g. received during the last 5
        minutes) need to
        be kept in memory. 

        Three or four bytes
        for the random number will be sufficient.

    
 

    
In order to allow for interoperability,
        a format should be specified.

    


      

    
I
        propose a NumericDate defining the UTC time concatenated with a
        random number
        with three bytes.

    
 

    
"Nonce" has not been officially registered
        by IANA. An IANA
        Considerations section should be added in draft-ietf-oauth-jwsreq-
            

          to register the "nonce" parameter.

    
 

    
On page 14, section 6.2., after the previous
        proposed text which is:

    
 

    
   Identifying
        the appropriate
        key MUST be done according to section 6 

           of RFC 7515 and using
        the Registered
        Header Parameter Names defined 

           in section 4.1 of RFC
        7515, e.g.
        using the Header Parameters "jku", 

           "jwk", "kid",
        "x5u", "x5c", "x5t", or "x5t#S256".

    
 

    
I proposed to add the following text: 

    
 

    
   To perform JWS Signature
        Validation, the
        "nonce" Header Parameter in

    
   the JOSE Header MUST be
        present and MUST be
        checked to verify that 

           the signed request is
        not the replay
        of a previous signed request.

    
 

    A section defining the nonce parameter should be
      added.

    
    
    
    
    
    
    

    

      

        

          

            

              

                
 8. Section 10.3
                    states: 

                  

                
10.3.  Request Source
                    Authentication 

                  

                
   The source of the
                    Authorization Request MUST always be verified.

                
   There are several
                    ways to do it in this specification. 

                  

                
   (a)  Verifying the JWS
                    Signature of the Request Object.

                
 It seems that the
                    case of using a JWE encrypted using a secret key
                    algorithm has been forgotten here. Please add it.

              

            

          

          
Accepted with modification. 

          
You mean, symmetric key algorithm, is that right? I would
            add "or verifying that the symmetric key for the JWE encryption is a correct one" 

            

        

      

    

    

    
    Accepted

      
    
    
    
    
    
    

    

      

        

          

            

              

                

                
 9. Section 10.3
                    states at its very end:

                
    An extension
                    specification

                       should be created
                    as a preventive measure to address potential

                       vulnerabilities
                    that have not yet been identified.

                


                  

                
Writing a document
                    for vulnerabilities that have not yet been
                    identified is speculative. It would rather be better
                    

                    either to remove this sentence or to explain what is
                    meant by it.

              

            

          

          
Reject. 

          
It is referring to the first paragraph of the
            sub-section. Also, precaution when security is in question
            is a good thing. 
              

            

        

      

    

    

    
    
This sentence is simply
        useless and thus should be
        deleted. Hence, I maintain this comment.

    

    

    

      

        

          

            

              

                
10. Section 11.1
                    states:

                
 11.1.  Collection
                      limitation

                
    When
                      the Client is being granted access to a protected
                      resource

                         containing
                      personal data, the Client SHOULD limit the
                      collection of

                         personal data
                      to that which is within the bounds of applicable
                      law

                         and strictly
                      necessary for the specified purpose(s).

                
 The presentation of personal
                    data should be limited whether or not the protected
                    resource contains personal data. 

                

              

            

          

          

            

              

                
It is proposed to
                    change this text into: 

                  

                
   When
                      the Client requests an access to a protected
                      resource, the Client

                         SHOULD limit
                      the presentation of personal data to that which is
                      within

                         the bounds of
                      applicable law and strictly necessary for the
                      specified

                         purpose(s).

              

            

          

          
Reject. 

          
You are not getting what OAuth does. The party that holds
            personal data is the authorization server / resource. 

          
It is not the client. The client is the party who is
            getting those "resources" which may contain personal data. 

          
Yes, the client can provide some personal data to the
            resource depending on what that resource endpoint is, but
            that is out of scope for OAuth. 

          
As far as OAuth is concerned, what is being sent from the
            client to the resource is the access token. 

          

        

      

    

    

    
    

      
The dispute is whether the protected resource
            contains or not personal data. 

            The data contained by the protected resource may
            well be public data (or/and personal data). 

            It does not need to be only "personal data".

      
 

      
Hence, I
            maintain my comment.

    

    

    

    

      

        

          

            

              

                

                
 11. Section 11.2.1
                    states: 

                  

                
11.2.1.  Request Disclosure 

                  

                
   This specification
                    allows extension parameters. 

                
 It would be useful
                    to name either all of them or some of them. RFC 6749
                    is not crystal clear about this.

              

            

          

          
Noted. 

          
RFC6749 only defines how to define extension parameters. 

          
This specification draws from OpenID Connect for some
            examples of extension parameters such as nonce. 

          
See section 4 for example.  

          

        

      

    

    
    


        See my earlier comments where client_id and nonce shall be
        mandatory.

    

    Denis

    
    
    
    
    
    
    

      

        

          

            

              

                

                
 Denis Pinkas (DP
                    Security Consulting SAS)

                 ==============================================================
                 

                

              

            

            

              

                
The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization
   Request (JAR)'
  <draft-ietf-oauth-jwsreq-11.txt> 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 2017-02-13. 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


   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be JWS
   signed and/or JWE encrypted so that the integrity, source
   authentication and confidentiality property of the Authorization
   Request is attained.  The request can be sent by value or by
   reference.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (Informational - IETF stream)
    rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream)
    rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream)
Note that some of these references may already be listed in the acceptable Downref Registry.


_______________________________________________
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

          

        

      

      
-- 

      

      

        
Nat Sakimura

        
Chairman of the Board, OpenID Foundation

      

    

    


    

  


--------------69CBEBA95C3BE4C4C2BE2340--


From nobody Mon Feb 13 10:09:40 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E17AD1297BD; Mon, 13 Feb 2017 10:09:38 -0800 (PST)
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.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148700937892.24914.355439693543276110.idtracker@ietfa.amsl.com>
Date: Mon, 13 Feb 2017 10:09:38 -0800
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-12.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 18:09:39 -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 of the IETF.

        Title           : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)
        Authors         : Nat Sakimura
                          John Bradley
	Filename        : draft-ietf-oauth-jwsreq-12.txt
	Pages           : 26
	Date            : 2017-02-13

Abstract:
   The authorization request in OAuth 2.0 described in RFC 6749 utilizes
   query parameter serialization, which means that Authorization Request
   parameters are encoded in the URI of the request and sent through
   user agents such as web browsers.  While it is easy to implement, it
   means that (a) the communication through the user agents are not
   integrity protected and thus the parameters can be tainted, and (b)
   the source of the communication is not authenticated.  Because of
   these weaknesses, several attacks to the protocol have now been put
   forward.

   This document introduces the ability to send request parameters in a
   JSON Web Token (JWT) instead, which allows the request to be signed
   with JSON Web Signature (JWS) and/or encrypted with JSON Web
   Encryption (JWE) so that the integrity, source authentication and
   confidentiality property of the Authorization Request is attained.
   The request can be sent by value or by reference.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12

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


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 Feb 13 13:59:45 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2099D12940D for ; Mon, 13 Feb 2017 13:59:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWmixHaSCoQ1 for ; Mon, 13 Feb 2017 13:59:41 -0800 (PST)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 50FF712941D for ; Mon, 13 Feb 2017 13:59:41 -0800 (PST)
Received: by mail-it0-x22f.google.com with SMTP id c7so5413283itd.1 for ; Mon, 13 Feb 2017 13:59:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=XFXF14+HwoQthHOldSxouXk3vtzAP1fHuMi2QrZm+fI=; b=a8FZjkH6ngkootFtGkkLaZ1WZentg7diDQDwmKnUQGiahLS2Y35o0vw7kVqfLbtlWI bxfCoMAGnb5GLDdg62bGCiaht1vnURF2gDJEpRB3sljKNfdAziTvRWfuow5zXu+ub6ty J6oGUSn/EnYDLYkJSf+p72ZTyJibIbAUzt6MWdKSd8aXdmpd6hyqec/9QAldRsllFpTB 0AU2/aY5nhjj6nXO96QeBNiKEV+5mOoZ5g149WBPjhnsudC1rlIVLJIZSzAQJ1wtARHh IVXn8EQ69ADVyHlAVx/z4/ZxjdTReg4uMQJCZVmF78qyY4gH2avuiEvViUvcu8FuPWr6 udWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XFXF14+HwoQthHOldSxouXk3vtzAP1fHuMi2QrZm+fI=; b=Cbus01Ix5/C3GGYLU5OJBwMjKipM4tAccrGpcn/8dSQuEeBNNBlec26N+lRH0ErHkA xd0IAtMljE9lI669pY8RI42vf8G/17ks19aVQvc1KHAUm5KpI0f5fSzjMkS9botujpti W4B85pbFFkPCtrwqIRyDmqDNul+pqxrPVKtcUkJYiwnAeTeajhi/EFKgzZxcbJCX4qEu 4AEtY7idmZpjY8cd3Wnn/mCOUm2+RpfZsONj+/39/AGmXqM29cfvoFp62dvddm0hhyrH MdBB3GDCnRBY1QWUNTZplS8pgQuou1BrX082QwJP/yzzDa/vfEoSQIH9nHCnXEsz1a/x 504Q==
X-Gm-Message-State: AMke39l0xxwpD4yiIcqCzGVFCmWiiTLNn8zcJ2iJipbUSofOEO0i+OYY5dr243DSEiQk08mZaNMeGxJKDqRvbg==
X-Received: by 10.107.133.223 with SMTP id p92mr26988999ioi.175.1487023180392;  Mon, 13 Feb 2017 13:59:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.44.9 with HTTP; Mon, 13 Feb 2017 13:59:39 -0800 (PST)
From: Maduranga Siriwardena 
Date: Mon, 13 Feb 2017 15:59:39 -0600
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a113ed57070d63a05487090b9
Archived-At: 
Subject: [OAUTH-WG] Clarification about compatibility between rfc6750 and rfc7662
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Feb 2017 21:59:43 -0000

--001a113ed57070d63a05487090b9
Content-Type: text/plain; charset=UTF-8

Hi All,

While going through [1] and [2] I noticed a small contradiction between the
standards.

Section 3 (The WWW-Authenticate Response Header Field) of [1] provides a
example with WWW-Authenticate header description error description
with "The access token expired".

This error description should have been obtained from the response of
introspection request sent to the authorization server. But according the
section 2.2 (Introspection Response) of [2], it is not recommended to
include any additional information about an inactive token, including why
the token is inactive.

So how these scenarios match with each other?

[1] https://tools.ietf.org/html/rfc6750
[2] https://tools.ietf.org/html/rfc7662

Thanks,
-- 
Maduranga Siriwardena
Software Engineer
WSO2 Inc.

--001a113ed57070d63a05487090b9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi All,

While going through [1] and [2]=
 I noticed a small contradiction between the standards.

Section 3 (The WWW-Authenticate Response Header Field) of [1] provide=
s a example with=C2=A0WWW-Authenticate header description error description=
 with=C2=A0"The access token expired".

T=
his error description should have been obtained from the response of intros=
pection request sent to the authorization server. But according the section=
 2.2 (Introspection Response) of [2], it is not recommended to include any =
additional information about an inactive token, including why the token is =
inactive.

So how these scenarios match with each o=
ther?


Thanks,
-- 
=

Maduranga Siriwardena
Software Engineer
WSO2 Inc.




--001a113ed57070d63a05487090b9--


From nobody Tue Feb 14 07:33:14 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA5D12968D; Tue, 14 Feb 2017 07:33:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVRQaZdeorK5; Tue, 14 Feb 2017 07:33:04 -0800 (PST)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 3F67612967F; Tue, 14 Feb 2017 07:33:01 -0800 (PST)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 477D07803B5; Tue, 14 Feb 2017 16:32:58 +0100 (CET)
To: oauth@ietf.org
References: <148700937892.24914.355439693543276110.idtracker@ietfa.amsl.com>
From: Denis 
Message-ID: <759cb8f3-1178-087a-65d6-16ebc64c5454@free.fr>
Date: Tue, 14 Feb 2017 16:32:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <148700937892.24914.355439693543276110.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: ietf@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-12.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Feb 2017 15:33:06 -0000

Nat,

This new version 12 contains nice editorial improvements. However, you 
have not yet responded to my email
from February 9 th sent during the LC which contains substantial comments.

Denis

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol of the IETF.
>
>          Title           : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)
>          Authors         : Nat Sakimura
>                            John Bradley
> 	Filename        : draft-ietf-oauth-jwsreq-12.txt
> 	Pages           : 26
> 	Date            : 2017-02-13
>
> Abstract:
>     The authorization request in OAuth 2.0 described in RFC 6749 utilizes
>     query parameter serialization, which means that Authorization Request
>     parameters are encoded in the URI of the request and sent through
>     user agents such as web browsers.  While it is easy to implement, it
>     means that (a) the communication through the user agents are not
>     integrity protected and thus the parameters can be tainted, and (b)
>     the source of the communication is not authenticated.  Because of
>     these weaknesses, several attacks to the protocol have now been put
>     forward.
>
>     This document introduces the ability to send request parameters in a
>     JSON Web Token (JWT) instead, which allows the request to be signed
>     with JSON Web Signature (JWS) and/or encrypted with JSON Web
>     Encryption (JWE) so that the integrity, source authentication and
>     confidentiality property of the Authorization Request is attained.
>     The request can be sent by value or by reference.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-12
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



From nobody Wed Feb 15 04:08:45 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F87129558; Wed, 15 Feb 2017 04:08:33 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Alexey Melnikov" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148716051341.17337.6756624161796452361.idtracker@ietfa.amsl.com>
Date: Wed, 15 Feb 2017 04:08:33 -0800
Archived-At: 
Cc: oauth@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org
Subject: [OAUTH-WG] Alexey Melnikov's No Record on draft-ietf-oauth-jwsreq-12: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 12:08:33 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-oauth-jwsreq-12: No Record

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In 5.2: a document defining HTTPS URI needs to be a normative
reference.

In 5.2.3: can you show an example of response (with relevant HTTP Header
Fields)? Or update example in 5.2 to include HTTP Header Fields.



From nobody Wed Feb 15 05:28:30 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E90129A2D for ; Wed, 15 Feb 2017 05:28:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0XgJGpODulC for ; Wed, 15 Feb 2017 05:28:27 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92ED5129A2B for ; Wed, 15 Feb 2017 05:28:27 -0800 (PST)
X-AuditID: 12074424-6b3ff70000001bfb-77-58a4577abac6
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by  (Symantec Messaging Gateway) with SMTP id 67.B4.07163.A7754A85; Wed, 15 Feb 2017 08:28:26 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v1FDSPYk017655; Wed, 15 Feb 2017 08:28:26 -0500
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v1FDSNrG026105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Feb 2017 08:28:25 -0500
To: Maduranga Siriwardena , oauth@ietf.org
References: 
From: Justin Richer 
Message-ID: <37a525b5-7352-0f4a-7a91-2fc600fb8b5d@mit.edu>
Date: Wed, 15 Feb 2017 08:28:17 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------9F736E847735C4E80C3FD697"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrFsVviTC4F6HisXE+1+ZLE6+fcXm wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGXsnbqNqeCdYcXGGacYGxiXqXYxcnBICJhI vL3v38XIySEk0MYk0fI6tIuRC8jeyChx59hnVgjnNpPEhv1fWUGqhAXCJY4fPs4EYosIeEvM bbvGDtEdILHn5j1GEJtNQFVi+poWsBpeASuJqbvfg9ksQPG98zeD2aICMRJ7++9D1QhKnJz5 hAXkIE6BQIlljSEgYWaBMIll2+4wTmDkm4WkahaSFIRtK3Fn7m5mCFteYvvbOVC2rsSibSvY YeLNW2czL2BkW8Uom5JbpZubmJlTnJqsW5ycmJeXWqRrrpebWaKXmlK6iREUvOwuKjsYu3u8 DzEKcDAq8fAWSC+OEGJNLCuuzD3EKMnBpCTKu95nSYQQX1J+SmVGYnFGfFFpTmrxIUYJDmYl Ed7boUA53pTEyqrUonyYlDQHi5I4r7hGY4SQQHpiSWp2ampBahFMVoaDQ0mCd0oYUKNgUWp6 akVaZk4JQpqJgxNkOA/Q8Ldgw4sLEnOLM9Mh8qcYFaXEedVBmgVAEhmleXC9oOSS8Paw6StG caBXhHlbQap4gIkJrvsV0GAmoMGscQtBBpckIqSkGhhXeESdqupV0n1nrbaRP+ZFfa5yxhu5 e0+dDDu2FWsEvIkSLegPbD7z5R3fLM7bjec1rnKk7eiSf21x1tGXVeP09XeJkW1Xzp/L/7SX NTDPp/X+J3GN6SdTF5y+8F3gQ8uzaV/MqyvDaneV2u2dXfJKTSVvSS1nt3jI1h0mc6x4jS7Y vjlhJKnEUpyRaKjFXFScCADWs84nCQMAAA==
Archived-At: 
Subject: Re: [OAUTH-WG] Clarification about compatibility between rfc6750 and rfc7662
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 13:28:29 -0000

This is a multi-part message in MIME format.
--------------9F736E847735C4E80C3FD697
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

These specs cover two different connections: 6750 is client to RS, 7662 
is RS to AS.

When the authorization server and the resource server are the same box, 
it will know exactly why the token isn't any good and it can react 
accordingly. The client doesn't actually care: note that the error 
response in the example is descriptive text and not a value to be parsed 
and acted upon.

In the case where they're a separate box (which is what introspection is 
set up for), the RS might not be allowed to know the details about the 
token not being good, and in any event it doesn't change how the RS 
responds to that situation.

So to use them together, you would respond with "active: false" from 
introspection and return a WWW-Authenticate header with "invalid_token" 
from the resource to the client, no description field needed.

  -- Justin

On 2/13/2017 4:59 PM, Maduranga Siriwardena wrote:
> Hi All,
>
> While going through [1] and [2] I noticed a small contradiction 
> between the standards.
>
> Section 3 (The WWW-Authenticate Response Header Field) of [1] provides 
> a example with WWW-Authenticate header description error description 
> with "The access token expired".
>
> This error description should have been obtained from the response of 
> introspection request sent to the authorization server. But according 
> the section 2.2 (Introspection Response) of [2], it is not recommended 
> to include any additional information about an inactive token, 
> including why the token is inactive.
>
> So how these scenarios match with each other?
>
> [1] https://tools.ietf.org/html/rfc6750 
> 
> [2] https://tools.ietf.org/html/rfc7662 
> 
>
> Thanks,
> -- 
> Maduranga Siriwardena
> Software Engineer
> WSO2 Inc.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------9F736E847735C4E80C3FD697
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
These specs cover two different connections: 6750 is client to
      RS, 7662 is RS to AS. 

    

    
When the authorization server and the resource server are the
      same box, it will know exactly why the token isn't any good and it
      can react accordingly. The client doesn't actually care: note that
      the error response in the example is descriptive text and not a
      value to be parsed and acted upon.

    
In the case where they're a separate box (which is what
      introspection is set up for), the RS might not be allowed to know
      the details about the token not being good, and in any event it
      doesn't change how the RS responds to that situation.

    
So to use them together, you would respond with "active: false"
      from introspection and return a WWW-Authenticate header with
      "invalid_token" from the resource to the client, no description
      field needed.

    

     -- Justin

    

    
On 2/13/2017 4:59 PM, Maduranga
      Siriwardena wrote:

    

    

      
      
Hi All,
        


        

        
While going through [1] and [2] I noticed a small
          contradiction between the standards.

        


        

        
Section 3 (The WWW-Authenticate Response Header Field) of
          [1] provides a example with WWW-Authenticate header
          description error description with "The access token expired".

        


        

        
This error description should have been obtained from the
          response of introspection request sent to the authorization
          server. But according the section 2.2 (Introspection Response)
          of [2], it is not recommended to include any additional
          information about an inactive token, including why the token
          is inactive.

        


        

        
So how these scenarios match with each other?

        


        

        
        
        


        

        
Thanks,

        -- 

        

          

            

              

                

                  

                    
Maduranga
                        Siriwardena

                    
Software
                        Engineer

                    
WSO2
                        Inc.

                  

                

              

            

          

        

      

      

      

      

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


    

    

  


--------------9F736E847735C4E80C3FD697--


From nobody Wed Feb 15 07:42:50 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358DC1294E0 for ; Wed, 15 Feb 2017 07:42:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo1X5ZC8wRKN for ; Wed, 15 Feb 2017 07:42:46 -0800 (PST)
Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01D7129489 for ; Wed, 15 Feb 2017 07:42:46 -0800 (PST)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs02.index.or.jp (Postfix) with ESMTP id A9C4A1968AB; Thu, 16 Feb 2017 00:42:45 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 5A5F14E0046; Thu, 16 Feb 2017 00:42:45 +0900 (JST)
Received: from nriea04.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id v1FFgj3g003893; Thu, 16 Feb 2017 00:42:45 +0900
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea04.index.or.jp with ESMTP id v1FFgi2c003892; Thu, 16 Feb 2017 00:42:45 +0900
Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v1FFgijH047759; Thu, 16 Feb 2017 00:42:44 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id v1FFgicq047758; Thu, 16 Feb 2017 00:42:44 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v1FFgitY047755; Thu, 16 Feb 2017 00:42:44 +0900
Received: from NatRZ4 (unknown [172.21.163.99]) by nrivpnfs01.index.or.jp (Postfix) with ESMTP id BA55BBF947; Thu, 16 Feb 2017 00:42:43 +0900 (JST)
From: "Nat Sakimura" 
To: "'Denis'" , 
References: <148700937892.24914.355439693543276110.idtracker@ietfa.amsl.com> <759cb8f3-1178-087a-65d6-16ebc64c5454@free.fr>
In-Reply-To: <759cb8f3-1178-087a-65d6-16ebc64c5454@free.fr>
Date: Thu, 16 Feb 2017 00:42:43 +0900
Message-ID: <013501d287a2$26c126d0$74437470$@nri.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
X-MailAdviser: 20141126
thread-index: AQJ0dUwS3CELHZbeKHFL0vhvzNfp/wIiwgtFoBVC1cA=
Content-Language: ja
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-12.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 15:42:49 -0000

Hi Denis, 

Your Feb. 9 mail came too late for this round of edit as all the edits
except dates were done by Feb. 8. 
Since then, I am continuously travelling and has been a bit challenging to
send out the response apart from doing a routine posting of the draft. 

Will respond to your Feb. 9 mail shortly. 

Nat

--
$B$3$N%a!<%k$O!"K\Mh$N08@h$NJ}$N$_$K8BDj$5$l$?5!L)>pJs$,4^$^$l$F$$(B
$B$k>l9g$,$4$6$$$^$9!#$*?4$"$?$j$N$J$$>l9g$O!"Aw?.e$2$^$9!#(B
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an intended recipient,
please notify the sender  and delete this e-mail.

> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Denis
> Sent: Wednesday, February 15, 2017 12:33 AM
> To: oauth@ietf.org
> Cc: ietf@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-12.txt
> 
> Nat,
> 
> This new version 12 contains nice editorial improvements. However, you
have
> not yet responded to my email from February 9 th sent during the LC which
> contains substantial comments.
> 
> Denis
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol of the IETF.
> >
> >          Title           : The OAuth 2.0 Authorization Framework: JWT
> Secured Authorization Request (JAR)
> >          Authors         : Nat Sakimura
> >                            John Bradley
> > 	Filename        : draft-ietf-oauth-jwsreq-12.txt
> > 	Pages           : 26
> > 	Date            : 2017-02-13
> >
> > Abstract:
> >     The authorization request in OAuth 2.0 described in RFC 6749
utilizes
> >     query parameter serialization, which means that Authorization
Request
> >     parameters are encoded in the URI of the request and sent through
> >     user agents such as web browsers.  While it is easy to implement, it
> >     means that (a) the communication through the user agents are not
> >     integrity protected and thus the parameters can be tainted, and (b)
> >     the source of the communication is not authenticated.  Because of
> >     these weaknesses, several attacks to the protocol have now been put
> >     forward.
> >
> >     This document introduces the ability to send request parameters in a
> >     JSON Web Token (JWT) instead, which allows the request to be signed
> >     with JSON Web Signature (JWS) and/or encrypted with JSON Web
> >     Encryption (JWE) so that the integrity, source authentication and
> >     confidentiality property of the Authorization Request is attained.
> >     The request can be sent by value or by reference.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-12
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-12
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at
> tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Wed Feb 15 09:04:30 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DE112955D; Wed, 15 Feb 2017 09:04:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7NWq6sH2P1v; Wed, 15 Feb 2017 09:04:26 -0800 (PST)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8CB3129483; Wed, 15 Feb 2017 09:04:25 -0800 (PST)
Received: by mail-wm0-x233.google.com with SMTP id c85so47159172wmi.1; Wed, 15 Feb 2017 09:04:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2TFoTuHAKAyrzg4OgS1NCYJWcBX6vTiRNj5UfMPM8kY=; b=WU3MgaUt0D3OU2fzoElfN0OGRJR21OL2QzC+Gcx1mAu4mIVNyaf+aqQbCwmz/OsFEC +9yUKBaSp5ygnxfawiAnRlidtKPFxog4A8zHWRvYPC6R8jOWXIbRygbrEvwrLv8Vfdc5 5k9d29SgGd6T9JnhjBlPDwtpEkB6Crkqw5xyIEXP9zZYhaYhF6F8oAwzqa73RPEP4SEi dkvozISIaNrwTXZRuFMalbNx1ppViCIdRtYuLinEvxDRCd+vClMEGObOCn50iUlDBPUp Q06cQKT6FjfS2ZSeOVrnMBSeUZy3IpMbsDvtZbm+LMhXpnEozRqWu1zr5dvMGUDWwmed AW+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2TFoTuHAKAyrzg4OgS1NCYJWcBX6vTiRNj5UfMPM8kY=; b=NRZ2i0rLR+2RMeLnN7KOMTKa2h1PG4ouTo6y0EzcP9+y6ybcM3LOMZEYj/oWCyZro6 B6btFnCqMLlNuPgliNx7kbZenzU+EvKlnc8RxaRz2Yn8lEo9cghQQF/+AFTfdxp/tpXL iOg4//qupxa9+j720HVoeydDHkJ+0Ui4bzGNlPk+wyRcLshz/wwVz1NluIyWATqCqvms JzSxaH0jKnBC3e4KpnIE+VKCaj3PtfKBz5qv3tX1bXsQo5Vb4bdwTVQl/7Xe6gTFqXmr vkWueBwCUrvWvedFtC200Agq/ZVX+4SZPoADDLg/10yQqujPb4Varf0gjHue6+AtL/gK SwHg==
X-Gm-Message-State: AMke39mtn5843HHr8GKugzu0rjpqupGKW8UiyDOq+e9n3ewy6Ppisr5bndko9GCGOGMedCK9oHNKwRJTWFnkNw==
X-Received: by 10.28.128.131 with SMTP id b125mr9136489wmd.7.1487178264285; Wed, 15 Feb 2017 09:04:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.80.138.65 with HTTP; Wed, 15 Feb 2017 09:04:23 -0800 (PST)
In-Reply-To: <81f50f3f-2f04-c74a-d47a-dad8cd9f715a@free.fr>
References: <148581788158.29828.4591033587037530374.idtracker@ietfa.amsl.com> <3a6b8cee-ff29-323e-9042-5df6e71a8d81@free.fr>  <81f50f3f-2f04-c74a-d47a-dad8cd9f715a@free.fr>
From: Nat Sakimura 
Date: Thu, 16 Feb 2017 02:04:23 +0900
Message-ID: 
To: Denis 
Content-Type: multipart/alternative; boundary=001a1142076c291714054894acbe
Archived-At: 
Cc: oauth , draft-ietf-oauth-jwsreq@ietf.org
Subject: Re: [OAUTH-WG] Last Call:  (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Feb 2017 17:04:29 -0000

--001a1142076c291714054894acbe
Content-Type: text/plain; charset=UTF-8

Hi Denis,

Thought John's response went to you as well but apparently not.

My replies inline:

On Fri, Feb 10, 2017 at 6:15 AM, Denis  wrote:

> Hi Nat,
>
> My replies to your proposed disposition of comments are embedded in the
> text.
>
[snip]

>  Section 4 states:
>>
>>
>>
>>
>> *   A Request Object (Section 2.1) is used to provide authorization
>> request parameters for an OAuth 2.0 authorization request.  It    contains
>> OAuth 2.0 [RFC6749] authorization request parameters    including extension
>> parameters**.  *
>>
>> RFC 6749 contains 75 pages, but does not contain a single occurrence of
>> the wording "authorization request parameter" nor of "extension parameter".
>> There should be either references to one or more specific sections of
>> this document or, even better, a list of the mandatory/recommended/possible
>> authorization request parameters as well as a list of
>> mandatory/recommended/possible extension parameters should be included in
>> this document.
>>
>> A clear distinction should be made between the parameters used to
>> authenticate the request and the other ones.
>>
>
> Reject.
> There are 4 flows in RFC6749. In each flow, there is a sub-section
> dedicated to the Authorization request.
> In them, the parameters used in the authorization request are very clearly
> indicated. For example,
>
> 4.1.1 .  Authorization Request
>
>    The client constructs the request URI by adding the following
>    parameters to the query component of the authorization endpoint URI ...
>
> It is very difficult to miss.
>
> Then, the possibility for the extension parameters are discussed in 8.2.
> Needless to say, those extension parameters are going to be discussed in
> other specifications.
> Thus, it would be misleading just to say the parameters defined in 4.1.1,
> 4.2.1, etc.
> As an editor, I feel better with the current language because it is at
> least not wrong nor misleading.
>
>
> draft-ietf-oauth-jwsreq-11 states on page 7.
>
>
>
>    To sign, JSON Web Signature (JWS) [RFC7515] is used.  The result is a
>
>    JWS signed JWT [RFC7519].  If signed, the Authorization Request
>
>    Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience)
>
>    as members, with their semantics being the same as defined in the JWT
>
>    [RFC7519] specification.
>
>
>
> This should be changed into:
>
>
>
>    To sign, JSON Web Signature (JWS) [RFC7515] is used.  The result is a
>
>    JWS signed JWT [RFC7519].  If signed, the Authorization Request
>
>    Object *MUST contain a client_id parameter* and SHOULD contain a
>    "iss" (issuer) *parameter* and an "aud" (audience) *parameter*, with
>    their semantics being the same as defined in the JWT RFC7519]
>    specification.
>
>
>
 I am kind of ok with the proposed text but if we do you want to single out
`client_id`, perhpas a reason should be added.
There are other REQIURED parameters in the Auhtorization Request defined in
RFC6749, you know.

> In section 5.2. Message Signature or MAC Validation, the text states:
>
>
>
>    When validating a JWS, the following steps are performed.
>
>
>
> (...)
>
>        See Section 10.6 for security considerations on algorithm
>
>        validation.
>
>
>
> There is no section 10.6 in this document. It seems to be section 10.3
>
> Anyway, it is not the right place to place requirements in a security
> considerations section and the appropriate text
> should be moved in the main body of the document.
>

Sorry, I cannot find the text you are refering to.


>
>
> RFC 6749 states in clause 4.  Obtaining Authorization on page
>
>
>
> 6.2.  JWS Signed Request Object
>
>
>
>    To perform JWS Signature Validation, the "alg" Header Parameter in
>
>    the JOSE Header MUST match the value of the pre-registered algorithm.
>
>    The signature MUST be validated against the appropriate key for that
>
>    "client_id" and algorithm.
>
>
>
> The important point is to provide guidance on how to map the client_id
> parameter with the appropriate key.
> There is none at the present time.
>
>
>
> Add:
>
>
>
>    Identifying the appropriate key MUST be done according to section 6
>    of RFC 7515 and using the Registered Header Parameter Names defined
>    in section 4.1 of RFC 7515, e.g. using the Header Parameters "jku",
>    "jwk", "kid", "x5u", "x5c", "x5t", or "x5t#S256".
>
>
>
>  4. The introduction states on page 4:
>
>>
>>
>>      (a) (integrity protection) The request can be signed so that the
>> integrity of the request can be checked ;
>>
>>
>>
>> This should be changed into:
>>
>>
>>
>>      (a) (integrity protection) The request can be authenticated either
>> using a digital signature or using encryption under a secret key
>>           so that the integrity of the request can be checked ;
>>
>
> Reject.
> This paragraph is talking about the integrity protection and not the
> source authentication.
> And even for source authentication, saying that encryption under a secret
> key is not accurate as it was discussed earlier in the WG mail.
>
> I am not sure if "Introduction" needs to state everything that is
> explained later. The idea of introduction probably is to give main points.
> The list is not an exhaustive list of the benefit of using JWT as the
> authorization request format. For example, being able to encrypt the
> request, which is not listed there, has an advantage of preventing MITB to
> eavesdrop the request. So I think it is ok as is.
>
> Integrity protection cannot be verified without knowing the source of the
> information.
>
Using encryption (which supports at the same time
> an integrity service when secret keys are being used) is another way to be
> able to check the integrity of the request.
>
>
>
> So I maintain may comment.
>

I think the issue is that if you encrypt with a asymmetric algorithm then
the receiver has no idea who encrypted it.
If encrypted with a symmetric key (not secret key) then you know that it
came from someone who has access to that key.
That works because we only support AEAD encryption.

You can use asymmetric encryption but you need to sign first if you want to
know who it is from.


>
>  5. The introduction states on page 4:
>
>>
>>
>> (d) (collection minimization) The request can be *signed* by a third
>> party attesting that the authorization request is compliant to certain
>> policy.
>>
>> The request is not *signed* by a third party.
>>
> However, later on, there is the following explanation:
>>
>>    In addition, it allows requests to be prepared by a third party so
>> that a client application cannot request
>>    more permissions than previously agreed.
>>
>>  If it is the intent, the sentence should be rephrased as:
>>
>> (d) (collection minimization) The request can be *verified* by a third
>> party attesting that the authorization request is compliant to certain
>> policy.
>>
> Reject
> The third party indeed signs the request on behalf of the client as the
> result of verification that the permission is the same as previously
> agreed.
>
>
> If it were the case, the client_id would indicate the name of the third
> party and the name of the user would be missing (or vice versa).
>

The value of `client_id` will be the requesting party.
The value of `iss` can be the third party.
But setting aside that, I guess your point actually is on the use of the
word "request". Authorization request is the entire thing that travels from
the client and not a part of it, and that is a fair point. Having said
that, I have a problem with your use of the word "verified". What about
this?

(d) (collection minimization) The data being requested can be *attested *by
> a third party that is compliant to collection minimization principle.
>

>
>  6. Section 10.1. the text states:
>>
>>
>>
>> *   When sending the authorization request object through "request"
>> parameter, it MUST either be signed using JWS [RFC7515] or encrypted
>> using JWE [RFC7516] with then considered appropriate algorithm.*
>>
>>  The wording" with then considered appropriate algorithm" is too vague.
>> This should be changed into:
>>
>>
>>
>> *   When sending the authorization request object through "request"
>> parameter, it MUST either be signed using JWS [RFC7515] or encrypted
>> using JWE [RFC7516] using a symmetric key algorithm.*
>>
>>  Reject.
>>
> In the above sentence, "*with then considered appropriate algorithm*"
>  applies both on JWS and JWE.
> The intent of the phrase is that a vulnerable algorithm should not be
> used.
>
> Also, I do not understand why the algorithm has to be symmetric key
> algorithm.
>
>
> Maybe, this explains why you didn't understand the previous comment. With
> public key encryption, it is not possible to authenticate
> the source of the request, while it is possible with secret key encryption
> when the encrypted data includes a cryptographic checksum
> like a hash value and an error propagation method for the encryption
> algorithm.
>

I understand this. My point is that this subsection is not talking about
what you just stated. This is a security consideration pointing out that an
alogrithm which has not become vulnerable must be used.

What you describe should instead go below the list (a)(b)(c) in section 5
or section 10.3.
"when symmetric keys are being used" probably is a bit too open to
interpretation. John is now creating a text on it.


>
>
> So I maintain my comment.
>
>  7. Section 10.2 states:
>>
>>    This means that the request object is going to be prepared fresh each
>>    time an authorization request is made and caching cannot be used.
>>
>>  What are the implications ? Is it required/recommended to use a nonce ?
>> The text should be made clearer.
>>
>> Reject.
> The implication is given right after the sentence. There is no variable
> called "nonce" in RFC6749. Since this document is just defining
> another encoding method for OAuth 2.0 authorization request as a
> framework, it does not mandate these.
> An extension specification should define those requirements.
>
>
> Note that this section belongs to the security considerations section
> which SHOULD NOT be normative and should only provide guidance.
>
>
>
> The sentence right after is the following:
>
>
>
>    It has a performance disadvantage, but where such disadvantage is
>
>    permissible, it should be considered.
>
>
>
> It does not provide any guidance.
>

Does it not? It is providing a guidance that the implementation should
consider not using cached request and create the request afresh each time
so that the entire request can be signed etc.


>
>
> The key point is that a parameter able to detect replay needs to be
> included in the request. This should be indicated in the normative part.
>

This security consideration is not about the replay attack but request
tampering.

It is unfortunate that RFC 7515 has not addressed replay protection of JWS
> and only mentions the problem is section 10.10 which is in the
> security considerations section. Here it is:
>

>
> 10.10.  Replay Protection
>
>    While not directly in scope for this specification, note that
>
>    applications using JWS (or JWE) objects can thwart replay attacks by
>
>    including a unique message identifier as integrity-protected content
>
>    in the JWS (or JWE) message and having the recipient verify that the
>
>    message has not been previously received or acted upon.
>
>
>
> The text on page 7 should be changed into:
>
>
>
>    To sign, JSON Web Signature (JWS) [RFC7515] is used.  The result is a
>    JWS signed JWT [RFC7519].  If signed, the Authorization Request
>    Object *MUST contain a client_id parameter* *and a "nonce"*
> *extension *   *parameter* *allowing to detect replay attacks *and SHOULD
> contain an "iss"
>    (issuer) *parameter* and an "aud" (audience) *parameter*, with their
>    semantics being the same as defined in the JWT specification[RFC7519].
>
>
>
> Note that Page 7 uses the "nonce" parameter in the example.
>

I agree that inclusion of nonce etc. to thwart the replay attack has to be
done in the normative section and not in the security consideration.
Having said that, as I stated before, this specification is just defining
another encoding for RFC6749. As the result, the replay protection etc. has
to be deferred to an extension spec, such as OIDC.


> JSON Web Token Claims are listed at: https://www.iana.org/
> assignments/jwt/jwt.xhtml
>
> "Nonce" is mentioned in OpenID Connect Core 1.0 incorporating errata set
> 1.
>
>
>
> It is described as :
>
>
>
> nonce
>
> Value used to associate a Client session with an ID Token
>
>
> This is too restrictive since now a nonce should be included in a JWS
> token.
>
>
>
> The registration is as follows:
>
>    - Parameter name: nonce
>    - Parameter usage location: Authorization Request
>    - Change controller: OpenID Foundation Artifact Binding Working Group
>    - openid-specs-ab@lists.openid.net
>    - Specification document(s): Section 3.1.2
>    
>    of this document
>    - Related information: None
>
>
> Section 3.1.2 states:
> 3.1.2.  Authorization Endpoint
>
> The Authorization Endpoint performs Authentication of the End-User. This
> is done by sending the User Agent to the Authorization Server's
> Authorization Endpoint for Authentication and Authorization, using request
> parameters defined by OAuth 2.0 and additional parameters
> and parameter values defined by OpenID Connect.
>
>
>
> Communication with the Authorization Endpoint MUST utilize TLS. See
> Section 16.17
> 
> for more information on using TLS
>
>
>
> This has nothing to do with the nonce. Hence the nonce registration
> information has been badly defined.
>
>
>
> The OpenID specification also states:
>
>
> "The Client SHOULD check the nonce value for replay attacks. The precise
> method for detecting replay attacks is Client specific".
>
>
>
> This does not allow to interoperate.
>
>
>
> Rather than correcting the registration information in the OpenID
> specification, it would be better to suppress it from the OpenID
> specification
> and incorporate it within an IETF RFC.
>

Out of scope for this specification.
Also, you should discuss something on OIDC on a sperarate list, not here.


>
>
> In order to avoid nonces to be kept in a memory for ever, a good practice
> is to split the nonce in two parts:
>
>    - one of them includes a UTC NumericDate using the format defined in
>    RFC 7519, and
>    - the other one includes a random number.
>
>
> In this way only recent nonces (e.g. received during the last 5 minutes)
> need to be kept in memory.
> Three or four bytes for the random number will be sufficient.
>
>
>
> In order to *allow for interoperability,* a format should be specified.
>
>
> I propose a NumericDate defining the UTC time concatenated with a random
> number with three bytes.
>
>
>
> "Nonce" has not been officially registered by IANA. An IANA Considerations
> section should be added in draft-ietf-oauth-jwsreq-
> to register the "nonce" parameter.
>

Everything related to nonce is out of scope. You should write a new I-D.


>
>
> On page 14, section 6.2., after the previous proposed text which is:
>
>
>
>    Identifying the appropriate key MUST be done according to section 6
>    of RFC 7515 and using the Registered Header Parameter Names defined
>    in section 4.1 of RFC 7515, e.g. using the Header Parameters "jku",
>    "jwk", "kid", "x5u", "x5c", "x5t", or "x5t#S256".
>
>
>
> I proposed to add the following text:
>
>
>
>    To perform JWS Signature Validation, the "nonce" Header Parameter in
>
>    the JOSE Header MUST be present and MUST be checked to verify that
>    the signed request is not the replay of a previous signed request.
>
>
> A section defining the nonce parameter should be added.
>

[snip]

>
>  9. Section 10.3 states at its very end:
>>
>>     An extension specification
>>    should be created as a preventive measure to address potential
>>    vulnerabilities that have not yet been identified.
>>
>>
>> Writing a document for vulnerabilities that have not yet been identified
>> is speculative. It would rather be better
>> either to remove this sentence or to explain what is meant by it.
>>
> Reject.
> It is referring to the first paragraph of the sub-section. Also,
> precaution when security is in question is a good thing.
>
>
> This sentence is simply useless and thus should be deleted. Hence, I
> maintain this comment.
>
> Agree to disagree.


>
> 10. Section 11.1 states:
>>
>>  *11.1.  Collection limitation*
>>
>>
>>
>>
>> *    When the Client is being granted access to a protected resource
>> containing personal data, the Client SHOULD limit the collection of
>> personal data to that which is within the bounds of applicable law    and
>> strictly necessary for the specified purpose(s).*
>>
>>  The *presentation* of personal data should be limited whether or not
>> the protected resource contains personal data.
>>
> It is proposed to change this text into:
>>
>>
>>
>>
>> *   When the Client requests an access to a protected resource, the
>> Client    SHOULD limit the presentation of personal data to that which is
>> within    the bounds of applicable law and strictly necessary for the
>> specified    purpose(s).*
>>
> Reject.
> You are not getting what OAuth does. The party that holds personal data is
> the authorization server / resource.
> It is not the client. The client is the party who is getting those
> "resources" which may contain personal data.
> Yes, the client can provide some personal data to the resource depending
> on what that resource endpoint is, but that is out of scope for OAuth.
> As far as OAuth is concerned, what is being sent from the client to the
> resource is the access token.
>
>
> The dispute is whether the protected resource contains or not personal
> data.
> The data contained by the protected resource may well be public data
> (or/and personal data).
> It does not need to be only "personal data".
>
>
>
> Hence, I maintain my comment.
>
> I do not understand your comment now. Your previous proposeal seems to be
unrelated to the above comment.


>
>  11. Section 11.2.1 states:
>>
>> 11.2.1.  Request Disclosure
>>
>>    This specification allows extension parameters.
>>
>>  It would be useful to name either all of them or some of them. RFC 6749
>> is not crystal clear about this.
>>
> Noted.
> RFC6749 only defines how to define extension parameters.
> This specification draws from OpenID Connect for some examples of
> extension parameters such as nonce.
> See section 4 for example.
>
>
> See my earlier comments where client_id and nonce shall be mandatory.
>
>
client_id is mandatory in RFC6749. Nonce is not defined in RFC6749 and
hence out of scope for this specification.


> Denis
>

[snip]

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

--001a1142076c291714054894acbe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Denis,=C2=A0

Thought John's resp=
onse went to you as well but apparently not.=C2=A0

My replies inline:=C2=A0

On Fri, Feb 10, 2017 at 6:15 AM, Denis <=
denis.ietf@free.fr<=
/a>> wrote:

 =20
   =20
 =20
  

    
Hi Nat,

      

      My replies to your proposed disposition of comments are embedded
      in the text.
[snip]=C2=A0

    

      

        

          

            

              

                
=C2=A0Section 4 states:

                
=C2=A0=C2=A0=C2=A0 A Request Object
                      (Section 2.1) is used to provide authorization

                      =
=C2=A0=C2=A0 request
                      parameters for an OAuth 2.0 authorization request.=C2=A0 It

                        =C2=A0=C2=A0 contains OAuth 2.0 [RFC6749]
                      authorization request parameters

                      =
=C2=A0=C2=A0 including
                      extension parameters.=
=C2=A0 

                
RFC 6749 contains 75 pages, but does
                    not contain a single occurrence of the wording
                    "authorization request parameter" nor of &quo=
t;extension
                    parameter". 

                    There should be either references to one or more
                    specific sections of this document or, even better,
                    a list of the mandatory/recommended/possible 

                    authorization request parameters as well as a list
                    of mandatory/recommended/possible extension
                    parameters should be included in this document.<=
/p>
                
A clea=
r distinction should be made
                    between the parameters used to authenticate the
                    request and the other ones.

              

            

          

          


          

          
Reject.=C2=A0

          
There are 4 flows in RFC6749. In each flow, there is a
            sub-section dedicated to the Authorization request.=C2=A0

          
In them, the parameters used in the authorization request
            are very clearly indicated. For example,=C2=A0

          


          

          

            
4.1.1.  Auth=
orization Request


   The client constructs the request URI by adding the following
   parameters to the query component of the authorization endpoint URI ... =


            

            It is very difficult to miss. 

          


          

          
Then, the possibility for the extension parameters are
            discussed in 8.2. Needless to say, those extension
            parameters are going to be discussed in other
            specifications.=C2=A0

          
Thus, it would be misleading just to say the parameters
            defined in 4.1.1, 4.2.1, etc.=C2=A0

          
As an editor, I feel better with the current language
            because it is at least not wrong nor misleading. 

          

        

      

    

    

   =20
    
draft-ietf-oauth-jwsreq-11<=
/span>
          states on page 7.

    
=C2=A0=


    
=C2=A0=C2=A0 To sign, JSON Web
        Signature (JWS) [RFC7515]
        is used.=C2=A0 The result is
        a

    
=C2=A0=C2=A0 JWS signed JWT [RFC7519].=C2=A0 I=
f signed, the
        Authorization Request

    
=C2=A0=C2=A0 Object SHOULD contain the
        Claims
        "iss" (issuer) and "aud" (audience)

    
=C2=A0=C2=A0 as members, with their
        semantics being the
        same as defined in the JWT

    
=C2=A0=C2=A0 [RFC7519] specification.<=
/p>
    
=C2=A0

    
This should be changed into:

    
=C2=A0

    
=C2=A0=C2=A0 To sign, JSON Web
        Signature (JWS) [RFC7515]
        is used.=C2=A0 The result is
        a

    
=C2=A0=C2=A0 JWS signed JWT [RFC7519].=C2=A0 I=
f signed, the
        Authorization Request

    
=C2=A0=C2=A0 Object MUST contain a
          client_id
          parameter and SHOULD contain a

        =C2=A0=C2=A0 "iss" (issuer) parameter
        and an "aud" (audience) parameter, with 

        =C2=A0=C2=A0 their semantics being
        the same as
        defined in the JWT RFC7519] 

        =C2=A0=C2=A0 specification.

    
=C2=A0
=C2=A0I am kind of ok with the =
proposed text but if we do you want to single out `client_id`, perhpas a re=
ason should be added.=C2=A0
There are other REQIURED parameters i=
n the Auhtorization Request defined in RFC6749, you know.=C2=A0
=


    
In sec=
tion
          5.2. Message Signature or MAC Validation, the text states:=


    
    
    
=C2=A0=


    
    
    
=
=C2=A0=C2=A0 When validating a JWS,
          the following steps
          are performed.

    
    
    
=C2=A0=


    
    
    
(...)<=
u>

    
    
    
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 See Section 10.6
          for security
          considerations on algorithm

    
    
    
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 validation.

    
    
    
=C2=A0=


    
    
    
There =
is no
          section 10.6 in this document. It seems to be section 10.3=


    
    
    
Anyway=
, it
          is not the right place to place requirements in a security
          considerations
          section and the appropriate text 

          should be moved in the main body of the
          document.

Sorry, I cannot find the text you are refering to.=C2=A0
=C2=A0<=
/div>

    
    
    
=C2=A0=


    
    
    
RFC 67=
49
          states in clause 4.=C2=A0 Obtaining
          Authorization on page 

    
=C2=A0=


    
6.2.=C2=A0 JWS Signed Request Object
    
=C2=A0

    
=C2=A0=C2=A0 To perform JWS Signature
        Validation, the
        "alg" Header Parameter in

    
=C2=A0=C2=A0 the JOSE Header MUST match the value of the
        pre-registered
        algorithm.

    
=C2=A0=C2=A0 The s=
ignature MUST be validated against the appropriate
          key for that

    
=C2=A0=C2=A0
        "client_id" and algorithm.

    
=C2=A0=


    
The
          important point is to provide guidance on how to map the c=
lient_id
          parameter with the appropriate key. 

          There
          is none at the present time.

    
    
    
=C2=A0=


    
    
    
Add:

    
=C2=A0=


    
=C2=A0=C2=A0 Identifying
        the appropriate
        key MUST be done according to section 6 

        =C2=A0=C2=A0 of RFC 7515 and using
        the Registered
        Header Parameter Names defined 

        =C2=A0=C2=A0 in section 4.1 of RFC
        7515, e.g.
        using the Header Parameters "jku", 

        =C2=A0=C2=A0 "jwk", "kid",
        "x5u", "x5c", "x5t", or "x5t#S25=
6".

    
=C2=A0=


   =20
   =20
   =20
   =20
   =20
    

    

      

        

          
=C2=A04. Th=
e introduction states
              on page 4:

          

            

              

                
=C2=A0

                
=C2=A0=C2=A0=C2=A0=C2=A0 (a) (integrity protection) T=
he
                    request can be signed so that the integrity of the
                    request can be checked=
 ;
                  

                
=C2=A0

                
This should be changed into:

                
=C2=A0

                
=C2=A0=C2=A0=C2=A0=C2=A0 (a) (integrity protection) T=
he
                    request can be authenticated either using a digital
                    signature or using encryption under a secret key 

                    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
so that the integrity of the request can
                    be checked ;

              

            

          

          


          

          
Reject.=C2=A0

          

            
This paragraph is talking about the integrity
              protection and not the source authentication.=C2=A0

            
And even for source authentication, saying that
              encryption under a secret key is not accurate as it was
              discussed earlier in the WG mail.=C2=A0

          

          


          

          
I am not sure if "Introduction" needs to state eve=
rything
            that is explained later. The idea of introduction probably
            is to give main points. The list is not an exhaustive list
            of the benefit of using JWT as the authorization request
            format. For example, being able to encrypt the request,
            which is not listed there, has an advantage of preventing
            MITB to eavesdrop the request. So I think it is ok as is.=C2=A0=


          


          

        

      

    

   =20
    
Integrity protection cannot be verified
        without knowing the source of
        the information.=C2=A0
Using encryption (=
which supports at the same
        time 

        an integrity
        service when secret keys are being used) is another way to be
        able to check the
        integrity of the request. 

    
=C2=A0

    
So I maintain may comment.

I think the issue is that if you encrypt with a asymmetric algorithm then =
the receiver has no idea who encrypted it.=C2=A0
If=
 encrypted with a symmetric key (not secret key) then you know that it came=
 from someone who has access to that key.=C2=A0
That=
 works because we only support AEAD encryption.

You can use asymmetric encrypti=
on but you need to sign first if you want to know who it is from.
=C2=A0

    


      

   =20
   =20
   =20
   =20
   =20
   =20
    

      

        

          
=C2=A05. The introduction states on pag=
e 4:

          

            

              

                
=C2=A0

                
(d) (collection minimization) The
                    request can be signed by a
                    third party attesting that the authorization request
                    is compliant to=
=
 certain policy.

                
The request is not signed by a third party. 

                  

              

            

          

          

            

              

                
However, later on,
                    there is the following explanation: 

                  

                
=C2=A0=C2=A0 In addition, it
                    allows requests to be prepared by a third party so
                    that a client application cannot request 

                    =C2=A0=C2=A0 more permissions than previously
                    agreed.=C2=A0 

                
=C2=A0If it is the intent,
                    the sentence should be rephrased as: 

                  

                
(d=
) (collection minimization) The
                    request can be verified by
                    a third party attesting that the authorization
                    request is compliant t=
o c=
ertain policy. 

                  

              

            

          

          
Reject

          
The third party indeed signs the request on behalf of the
            client as the result of verification that the permission is
            the same as previously agreed.=C2=A0 

          

        

      

    

    

   =20
    
If it were the case, the client_id would
        indicate the name of the third
        party and the name of the user would be missing (or vice versa).

The value of `client_id` wil=
l be the requesting party.=C2=A0
The value of `iss` can be the th=
ird party.=C2=A0
But setting aside that, I guess your point actua=
lly is on the use of the word "request". Authorization request is=
 the entire thing that travels from the client and not a part of it, and th=
at is a fair point. Having said that, I have a problem with your use of the=
 word "verified". What about this?=C2=A0
(d) (collection minimization)=
 The data being requested can be atte=
sted=C2=A0by a third party that is compliant=C2=A0=
to=C2=
=A0collection minimization principle.=C2=A0=C2=A0
<=
/blockquote>


    

    

      

        

          

            

              

                

                
=C2=A06. Section 10.1. the
                    text states: 

                  

                
=
=C2=A0=C2=A0 When
                      sending the authorization request object through
                      "request"

                      =
=C2=A0=C2=A0 parameter, it
                      MUST either be signed using JWS [RFC7515] or
                      encrypted

                      =
=C2=A0=C2=A0 using JWE
                      [RFC7516] with then considered appropriate
                      algorithm.

                
=C2=A0The wording" with then conside=
red
                    appropriate algorithm" is too vague. This
                    should be changed into:

                
=
=C2=A0=C2=A0 When
                      sending the authorization request object through
                      "request"

                      =
=C2=A0=C2=A0 parameter, it
                      MUST either be signed using JWS [RFC7515] or
                      encrypted

                      =
=C2=A0=C2=A0 using JWE
                      [RFC7516] using a symmetric key
                        algorithm.

                
=C2=A0Reject.=C2=A0

              

            

          

          
In the above sentence, "with then considered
                appropriate algorithm" =C2=A0applies both o=
n JWS
            and JWE.=C2=A0

          
The intent of the phrase is that a vulnerable algorithm
            should not be used.=C2=A0

          


          

          
Also, I do not understand why the algorithm has to be
            symmetric key algorithm. 

          

        

      

    

    

   =20
    
Maybe, this explains why you didn't
        understand the previous comment.
        With public key encryption, it is not possible to authenticate 

        the source of
        the request, while it is possible with secret key encryption
        when the encrypted
        data includes a cryptographic checksum 

        like a hash value and an error
        propagation method for the encryption algorithm.

I understand this. My point is that this sub=
section is not talking about what you just stated. This is a security consi=
deration pointing out that an alogrithm which has not become vulnerable mus=
t be used.=C2=A0

What you describe should instead =
go below the list (a)(b)(c) in section 5 or section 10.3.=C2=A0
&=
quot;when symmetric ke=
ys are being used" probably is a bit too open to interpretation. John =
is now creating a text on it.=C2=A0
=C2=A0
<=
/u>

    
=C2=A0

    
So I maintain my comment.

    

    

    

      

        

          

            

              

                

                
=C2=A07. Section 10.2
                    states: 

                  

                
=C2=A0=C2=A0 This means that the
                    request object is going to be prepared fresh each

                      =C2=A0=C2=A0 time an authorization request is =
made and caching cannot
                    be used.=C2=A0 

                
=C2=A0What are the
                    implications ? Is it required/recommended to use a
                    nonce ? The text should be made clearer. 

                

              

            

          

          
Reject.=C2=A0

          
The implication is given right after the sentence. There
            is no variable called "nonce" in RFC6749. Since this
            document is just defining 

            another encoding method for OAuth 2.0 authorization request
            as a framework, it does not mandate these. 

            An extension specification should define those requirements.
            

          

        

      

    

    

   =20
    
Note that this section belongs to the
        security considerations section
        which SHOULD NOT be normative and should only provide guidance.
        

    
=C2=A0

    
The sentence right after is the following:

    
=C2=A0=


    
=C2=A0=C2=A0 It has a performance
        disadvantage, but
        where such disadvantage is

    
=C2=A0=C2=A0 permissible, it should be
        considered.

    
=C2=A0=


    
It does not provide any guidance.

Does it not? It is providing a guidance that the implementation sh=
ould consider not using cached request and create the request afresh each t=
ime so that the entire request can be signed etc.=C2=A0
=C2=A0
=
 

    
=C2=A0

    
The key point is that a parameter able to
        detect replay needs to be
        included in the request. This should be indicated in the
        normative part. 

This security consideration is not about the replay attack but request t=
ampering.=C2=A0

It is
        unfortunate that RFC 7515 has not addressed replay protection of
        JWS and only
        mentions the problem is section 10.10 which is in the 

        security considerations
        section. Here it is:=C2=A0
=


    
=C2=A0=


    
10.10.=C2=A0 Replay
        Protection

    
=C2=A0=C2=A0 While
        not directly in scope
        for this specification, note that

    
=C2=A0=C2=A0 applications
        using JWS (or
        JWE) objects can thwart replay attacks by

    
=C2=A0=C2=A0 including
        a unique message
        identifier as integrity-protected content

    
=C2=A0=C2=A0 in
        the JWS (or JWE) message
        and having the recipient verify that the

    
=C2=A0=C2=A0 message
        has not been
        previously received or acted upon.

    
=C2=A0=


    
The text on page 7 should be changed
        into:

    
=C2=A0=


    
=C2=A0=C2=A0 To sign, JSON Web
        Signature (JWS) [RFC7515]
        is used.=C2=A0 The result is
        a

        =C2=A0=C2=A0 JWS signed JWT
        [RFC7519].=C2=A0 If signed,
        the Authorization Request

        =C2=A0=C2=A0 Object MUST
          contain a client_id
          parameter and a "nonce" extension 

        =C2=A0=C2=A0 parameter
      allowing to detect
          replay attacks and SHOULD
        contain an "iss" 

        =C2=A0=C2=A0 (issuer) parameter
        and an
        "aud" (audience) parameter, with their 

        =C2=A0=C2=A0 semantics being the
        same as defined
        in the JWT specification[RFC7519].

    
=C2=A0=


    
Note that Page 7 uses the
        "nonce" parameter in the example.

I agree that inclusion of nonce etc. to thwa=
rt the replay attack has to be done in the normative section and not in the=
 security consideration.=C2=A0
Having said that, as I stated befo=
re, this specification is just defining another encoding for RFC6749. As th=
e result, the replay protection etc. has to be deferred to an extension spe=
c, such as OIDC.=C2=A0
=C2=A0
 =


    
JSON Web Token
        Claims are listed at: https://www.iana.org/assign=
ments/jwt/jwt.xhtml

    
"Nonce" is mentioned in OpenID Connect Core
        1.0 incorporating
        errata set 1. 

    
=C2=A0

    
It is described as :

    
=C2=A0

    

      
        

          
            
nonce

          		
          
            
Value used to assoc=
iate a Client session
                with an ID Token<=
/span>

          		
        

      
    

    


      

    
This is too restrictive since now a nonce
        should be included in a JWS
        token.

    
=C2=A0

    
The registration is as follows:

    
    
      
  • Parameter
          name: nonce =

    • 
      
  • Parameter
          usage location: Authorization Request 
    • 
      
  • Change
          controller: OpenID Foundation Artifact Binding Working Group -
          openid-s=
pecs-ab@lists.openid.net 
    • 
      
  • Specification
          document(s): Section=C2=A03.1.2 of th=
is
          document 
    • 
      
  • Related information: None 
    • 
    

    


      

    
Section 3.1.2 states:

    
3.1.2.=C2=A0
        Authorization Endpoint

    
The Authorization Endpoint performs
        Authentication of the End-User. This
        is done by sending the User Agent to the Authorization Server's
        

        Authorization
        Endpoint for Authentication and Authorization, using request
        parameters defined
        by OAuth 2.0 and additional parameters 

        and parameter values defined by OpenID
        Connect. 

    
=C2=A0

    
Communication with the Authorization
        Endpoint MUST utilize TLS. See Section=C2=A016.17=

        for more
        information on using TLS

    
=C2=A0

    
This has nothing to do with the nonce. Hence
        the nonce registration
        information has been badly defined. 

    
=C2=A0

    
The OpenID specification also states:

    


      

    
 

    
=
"The Client
          SHOULD check the nonce value for replay
          attacks. The precise method for detecting replay
          attacks is Client specific".

    
=C2=A0

    
This does not allow to interoperate.

    
=C2=A0

    
Rather than correcting the registration
        information in the OpenID
        specification, it would be better to suppress it from the OpenID
        specification
        

        and incorporate it within an IETF RFC.

Out of scope for this specification.=C2=A0
A=
lso, you should discuss something on OIDC on a sperarate list, not here.=C2=
=A0
=C2=A0

    
=C2=A0

    
In order to avoid nonces to be kept in a
        memory for ever, a good
        practice is to split the nonce in two parts: 

      

    
    
      
  • one of them
          includes a UTC N=
umericDate
            using the format defined in RFC 7519, and 
    • 
      
  • the other one
          includes a random number. 
    
        
    • 
    

    


        In
        this way only recent nonces (e.g. received during the last 5
        minutes) need to
        be kept in memory. 

        Three or four bytes
        for the random number will be sufficient.

    
=C2=A0

    
In order to allow for interoperability,
        a format should be specified.

    


      

    
I
        propose a NumericDate defining the UTC time concatenated with a
        random number
        with three bytes.

    
=C2=A0

    
"Nonce" has not been officially registered
        by IANA. An IANA
        Considerations section should be added in draft-ietf-oauth-jwsreq-
            

          to register the "nonce" parameter.

Everything related to nonce is out of scope. You shoul=
d write a new I-D.=C2=A0
=C2=A0

    
=C2=A0

    
On page 14, section 6.2., after the previous
        proposed text which is:

    
=C2=A0

    
=C2=A0=C2=A0 Identifying
        the appropriate
        key MUST be done according to section 6 

        =C2=A0=C2=A0 of RFC 7515 and using
        the Registered
        Header Parameter Names defined 

        =C2=A0=C2=A0 in section 4.1 of RFC
        7515, e.g.
        using the Header Parameters "jku", 

        =C2=A0=C2=A0 "jwk", "kid",
        "x5u", "x5c", "x5t", or "x5t#S25=
6".

    
=C2=A0

    
I proposed to add the following text: 

    
=C2=A0

    
=C2=A0=C2=A0 To perform JWS Signature
        Validation, the
        "nonce" Header Parameter in

    
=C2=A0=C2=A0 t=
he JOSE Header MUST be
        present and MUST be
        checked to verify that 

        =C2=A0=C2=A0 the signed request is
        not the replay
        of a previous signed request.

    
=C2=A0=


    A section defining the nonce parameter should be
      added.

[snip]=C2=A0

=

=C2=A09. Section 10.3
                    states at its very end:

                
=C2=A0=C2=A0=C2=A0 An extension
                    specification

                    =
=C2=A0=C2=A0 should be created
                    as a preventive measure to address potential

                    =
=C2=A0=C2=A0 vulnerabilities
                    that have not yet been identified.

                


                  

                
Writing a document
                    for vulnerabilities that have not yet been
                    identified is speculative. It would rather be better
                    

                    either to remove this sentence or to explain what is
                    meant by it.

              

            

          

          
Reject.=C2=A0

          
It is referring to the first paragraph of the
            sub-section. Also, precaution when security is in question
            is a good thing.=C2=A0
              

            

        

      

    

    

   =20
    
This sentence is simply
        useless and thus should be
        deleted. Hence, I maintain this comment.

    
Agree to disagree.=C2=A0
=C2=A0

    

    

      

        

          

            

              

                
10. Section 11.1
                    states:

                
=C2=A011.1.=
=C2=A0 Collection
                      limitation

                
=C2=A0=C2=A0=C2=A0 When
                      the Client is being granted access to a protected
                      resource

                      =
=C2=A0=C2=A0 containing
                      personal data, the Client SHOULD limit the
                      collection of

                      =
=C2=A0=C2=A0 personal data
                      to that which is within the bounds of applicable
                      law

                      =
=C2=A0=C2=A0 and strictly
                      necessary for the specified purpose(s).

                
=C2=A0The presentation of personal
                    data should be limited whether or not the protected
                    resource contains personal data. 

                

              

            

          

          

            

              

                
It is proposed to
                    change this text into: 

                  

                
=
=C2=A0=C2=A0 When
                      the Client requests an access to a protected
                      resource, the Client

                      =
=C2=A0=C2=A0 SHOULD limit
                      the presentation of personal data to that which is
                      within

                      =
=C2=A0=C2=A0 the bounds of
                      applicable law and strictly necessary for the
                      specified

                      =
=C2=A0=C2=A0 purpose(s).

              

            

          

          
Reject.=C2=A0

          
You are not getting what OAuth does. The party that holds
            personal data is the authorization server / resource.=C2=A0
          
It is not the client. The client is the party who is
            getting those "resources" which may contain personal =
data.=C2=A0

          
Yes, the client can provide some personal data to the
            resource depending on what that resource endpoint is, but
            that is out of scope for OAuth.=C2=A0

          
As far as OAuth is concerned, what is being sent from the
            client to the resource is the access token. 

          

        

      

    

    

   =20
    

      
The dispute is whether th=
e protected resource
            contains or not personal data. 

            The data contained by the protected resource may
            well be public data (or/and personal data). 

            It does not need to be only "personal data".

      
=C2=A0

      
Hence, I
            maintain my comment.

    

    
I do not understand your comment now. Your =
previous proposeal seems to be unrelated to the above comment.=C2=A0
<=
div>=C2=A0

    

    

      

        

          

            

              

                

                
=C2=A011. Section 11.2.1
                    states: 

                  

                
11.2.1.=C2=A0 Request Disclosure 

                  

                
=C2=A0=C2=A0 This specification
                    allows extension parameters. 

                
=C2=A0It would be useful
                    to name either all of them or some of them. RFC 6749
                    is not crystal clear about this.

              

            

          

          
Noted.=C2=A0

          
RFC6749 only defines how to define extension parameters.=C2=
=A0

          
This specification draws from OpenID Connect for some
            examples of extension parameters such as nonce.=C2=A0

          
See section 4 for example.=C2=A0 

          

        

      

    

   =20
    


        See my earlier comments where client_id and nonce shall be
        mandatory.

    

client_id is mandatory in RF=
C6749. Nonce is not defined in RFC6749 and hence out of scope for this spec=
ification.=C2=A0
=C2=A0

    Denis

[snip]=C2=A0

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




--001a1142076c291714054894acbe--


From nobody Wed Feb 15 16:20:45 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 143A21296EE; Wed, 15 Feb 2017 16:20:40 -0800 (PST)
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.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148720444007.31614.4351735589682369445.idtracker@ietfa.amsl.com>
Date: Wed, 15 Feb 2017 16:20:40 -0800
Archived-At: 
Cc: oauth@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org
Subject: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwsreq-12: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 00:20:40 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-jwsreq-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- intro: "attacks... have been identified." yells out for a
reference - it'd be a good bit better if implementers could
easily find details of some such attacks, so I hope you add
some refs here.

- section 3; WAP? Really? I'm surprised any WAP technology
would still be in use, even on feature-phones. Do you really
need this?

- section 4: I think it will turn out to be an error to allow
for mixing query parameters and protected parameters (in a
Request Object) in a single request. Do you really need that
level of flexibility? It'd be simpler and less likely to be
attackable to insist that all parameters be in the Request
Object if one is used. (See also section 11.2.1 below.)

- section 10: Is there nothing to be said about the new
indirection caused by the request_uri? I'd have thought there
were some corner cases that'd warrant a mention, e.g. if some
kind of deadlock or looping could happen, or if one client (in
OAuth terms) could use a request_uri value as a way to attempt
attacks (to be assisted by an innocent browser) against some
resource owner.

- section 11: thanks for that, it's good.

- section 11: Saying that an ISO thing is "good to follow" is
quite weak IMO. (And is that ISO spec accessible? Hmm...  it
seems that one needs to accept cookies to get it which is
wonderfully ironic;-) If the authors have the energy, I'd
suggest trying to find better guidance that's more publically
available in a privacy-friendly manner. (Or just drop the ISO
reference if 6973 is good enough.)



From nobody Wed Feb 15 19:26:34 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C45CF129C8B; Wed, 15 Feb 2017 19:26:31 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148721559179.31568.17364533591826818865.idtracker@ietfa.amsl.com>
Date: Wed, 15 Feb 2017 19:26:31 -0800
Archived-At: 
Cc: oauth@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org
Subject: [OAUTH-WG] Ben Campbell's Yes on draft-ietf-oauth-jwsreq-12: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 03:26:32 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-oauth-jwsreq-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 4, "Since it is a JWT, JSON strings MUST be represented
   in UTF-8. ": Is that a new requirement, or a statement of fact about
an existing JWT requirement?

- 5.2: I'm not sure all readers will understand the meaning of "feature
phone".  Also, WAP and 2G don't seem all that relevant in 2017.

- 5.2.1, first sentence, "The URL MUST
   be HTTPS URL.": Is that redundant to the similar requirement in the
previous section? That instance had an "unless" clause, but this one does
not.

--2nd paragraph: "... MUST have appropriate entropy for its lifetime."
Can you offer discussion (or a reference) for what constitutes
"appropriate entropy"?

-- 3rd paragraph: Is it reasonable that one would know if TLS would offer
adequate authentication at the time of the signing decision?

- 5.2.3, 2nd paragraph: "SHOULD use a unique URI": Why not MUST? Would it
ever be reasonable to not do this?

- 6.1, 2nd paragraph: What if validation fails?

- 13: Do you want this in the final RFC? If not, it would be wise to add
a note to the RFC editor to that effect.



From nobody Thu Feb 16 02:31:20 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C621F129482; Thu, 16 Feb 2017 02:31:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "Mirja Kuehlewind" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148724107880.15846.17288887741708916676.idtracker@ietfa.amsl.com>
Date: Thu, 16 Feb 2017 02:31:18 -0800
Archived-At: 
Cc: oauth@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org
Subject: [OAUTH-WG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-oauth-jwsreq-12=3A_=28with_COMMENT=29?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 10:31:19 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-oauth-jwsreq-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Two minor questions:
- Should this document maybe update rfc6749?
- Should this be like this?
OLD
""request" and "request_uri" parameters MUST NOT be included in Request
Objects."
NEW
""request" and "request_uri" parameters MUST NOT be both included in 
Request Objects."



From nobody Thu Feb 16 02:37:23 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2FE1294F7; Thu, 16 Feb 2017 02:37:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=JI8vmrdQ; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Hzh6xBSi
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3X1hPpZnUGY; Thu, 16 Feb 2017 02:37:20 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1025A129482; Thu, 16 Feb 2017 02:37:20 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9656F20500; Thu, 16 Feb 2017 05:37:18 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 16 Feb 2017 05:37:18 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=NXMQ8Ct7mKudy3H KMCXvwIJWKzA=; b=JI8vmrdQn2Bswg2NoSpu7G5yxMNzeq6+ylLbrYZj81iQMxQ 7ORrDc2aE2ht9l9RTv4XH7gvtPeisLv5UI63BfezXLWb9OSqSSYE95PpRpoIvv4W LufW/1ugR4O8cNdbzxdP0fNA77rY+TJT7RgSCKU/rsFJZ8aPfCgj3Hstda94=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=NXMQ8Ct7mKudy3HKMCXvwIJWKzA=; b=Hzh6xBSicRL0HzJ4wDJJ 7VPmqNuhP+dJbo0ms/JBIeOhVmpzmk56kxs/J0kYjHv4y4xvtbQqFRuP9CBGGrM/ ZaTNYEK5REwLhUIfyIZgQ9W/KTSBMJrcMPLc+nyQCrIM107wI3Azghg+q2qHOM6i DFzLVijD391Ja6ygmdHVojA=
X-ME-Sender: 
X-Sasl-enc: D1zDB1QVc26HmUZXSNaJMsQFLnMdVp5WsJa3jLvYH1P8 1487241438
Received: from [10.229.165.214] (unknown [185.69.145.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 4F0CD7E2E5; Thu, 16 Feb 2017 05:37:18 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Alexey Melnikov 
X-Mailer: iPhone Mail (13G35)
In-Reply-To: <148724107880.15846.17288887741708916676.idtracker@ietfa.amsl.com>
Date: Thu, 16 Feb 2017 10:48:46 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <148724107880.15846.17288887741708916676.idtracker@ietfa.amsl.com>
To: Mirja Kuehlewind 
Archived-At: 
Cc: oauth-chairs@ietf.org, The IESG , draft-ietf-oauth-jwsreq@ietf.org, oauth@ietf.org
Subject: Re: [OAUTH-WG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-oauth-jwsreq-12=3A_=28with_COMMENT=29?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 10:37:21 -0000

Hi Mirja,

> On 16 Feb 2017, at 10:31, Mirja Kuehlewind  wrote:

 (Snip)
> - Should this be like this?
> OLD
> ""request" and "request_uri" parameters MUST NOT be included in Request
> Objects."
> NEW
> ""request" and "request_uri" parameters MUST NOT be both included in=20
> Request Objects."

You can't have either. Your new text implies that including one of them is O=
k, which is incorrect.



From nobody Thu Feb 16 02:51:53 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C411299F6 for ; Thu, 16 Feb 2017 02:51:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level: 
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1X_aUNIn5ab for ; Thu, 16 Feb 2017 02:51:50 -0800 (PST)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F0A129482 for ; Thu, 16 Feb 2017 02:51:49 -0800 (PST)
Received: (qmail 21928 invoked from network); 16 Feb 2017 11:45:07 +0100
Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated);  16 Feb 2017 11:45:06 +0100
To: Alexey Melnikov 
References: <148724107880.15846.17288887741708916676.idtracker@ietfa.amsl.com> 
From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= 
Message-ID: <6e35b9f8-dd41-0da0-7ee5-210566110ae8@kuehlewind.net>
Date: Thu, 16 Feb 2017 11:45:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: oauth@ietf.org, draft-ietf-oauth-jwsreq@ietf.org, oauth-chairs@ietf.org, The IESG 
Subject: Re: [OAUTH-WG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-oauth-jwsreq-12=3A_=28with_COMMENT=29?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 10:51:51 -0000

Hi Alexey,

sorry my fault, I read redirect_uri instead of request_uri and was confused...

Mirja


On 16.02.2017 11:48, Alexey Melnikov wrote:
> Hi Mirja,
>
>> On 16 Feb 2017, at 10:31, Mirja Kuehlewind  wrote:
>
>  (Snip)
>> - Should this be like this?
>> OLD
>> ""request" and "request_uri" parameters MUST NOT be included in Request
>> Objects."
>> NEW
>> ""request" and "request_uri" parameters MUST NOT be both included in
>> Request Objects."
>
> You can't have either. Your new text implies that including one of them is Ok, which is incorrect.
>
>


From nobody Thu Feb 16 03:43:04 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6D4129AB8; Thu, 16 Feb 2017 03:42:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Alexey Melnikov" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148724537375.15981.8662422383544692244.idtracker@ietfa.amsl.com>
Date: Thu, 16 Feb 2017 03:42:53 -0800
Archived-At: 
Cc: oauth@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org
Subject: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-jwsreq-12: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 11:42:54 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-oauth-jwsreq-12: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

When referencing RFC 6125 you need to provide more details. In
particular, you need to pretty much answer every question in section 3 of
RFC 6125: 

One example of how this might look like is in Section 9.2 of
.
For your convenience the relevant text is pasted below:

   Routers MUST also verify the cache's TLS server certificate, using
   subjectAltName dNSName identities as described in [RFC6125], to
avoid
   man-in-the-middle attacks.  The rules and guidelines defined in
   [RFC6125] apply here, with the following considerations:

      Support for DNS-ID identifier type (that is, the dNSName identity
      in the subjectAltName extension) is REQUIRED in rpki-rtr server
      and client implementations which use TLS.  Certification
      authorities which issue rpki-rtr server certificates MUST support
      the DNS-ID identifier type, and the DNS-ID identifier type MUST
be
      present in rpki-rtr server certificates.

      DNS names in rpki-rtr server certificates SHOULD NOT contain the
      wildcard character "*".

      rpki-rtr implementations which use TLS MUST NOT use CN-ID
      identifiers; a CN field may be present in the server
certificate's
      subject name, but MUST NOT be used for authentication within the
      rules described in [RFC6125].

The only thing missing from the above is explicit mentioning that SRV-ID
and URI-ID are not used. (I think the same should apply to your
document.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In 5.2: a document defining HTTPS URI needs to be a normative
reference.

In 5.2.3: can you show an example of response (with relevant HTTP Header
Fields)? Or update example in 5.2 to include HTTP Header Fields.



From nobody Thu Feb 16 03:55:57 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BC4129735; Thu, 16 Feb 2017 03:55:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQGvKadaARvb; Thu, 16 Feb 2017 03:55:50 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1650B129563; Thu, 16 Feb 2017 03:55:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3173F2CEB1; Thu, 16 Feb 2017 13:55:49 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM4-0O1cINg1; Thu, 16 Feb 2017 13:55:48 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 7CF842CCBA; Thu, 16 Feb 2017 13:55:48 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_D4DDE6F9-30B0-4A43-B8EB-E8B1E3CFDC3A"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Jari Arkko 
In-Reply-To: <148607662042.13885.2832003093930390561.idtracker@ietfa.amsl.com>
Date: Thu, 16 Feb 2017 13:55:47 +0200
Message-Id: 
References: <148607662042.13885.2832003093930390561.idtracker@ietfa.amsl.com>
To: Joel Halpern 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: Gen art , oauth@ietf.org, draft-ietf-oauth-jwsreq.all@ietf.org
Subject: Re: [OAUTH-WG] [Gen-art] Review of draft-ietf-oauth-jwsreq-11
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 11:55:52 -0000

--Apple-Mail=_D4DDE6F9-30B0-4A43-B8EB-E8B1E3CFDC3A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Many thanks for your review, Joel.

I have balloted no-objection for this document on today=92s IESG =
telechat.

Jari

On 03 Feb 2017, at 01:03, Joel Halpern  wrote:

> Reviewer: Joel Halpern
> Review result: Not Ready
>=20
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>=20
> For more information, please see the FAQ at
>=20
> .
>=20
> Document: draft-ietf-oauth-jwsreq-??
> Reviewer: Joel Halpern
> Review Date: 2017-02-02
> IETF LC End Date: 2017-02-13
> IESG Telechat date: 2017-02-16
>=20
> Summary: This document is ready for publication as a Proposed
> Standard
>=20
> Major issues: N/A
>=20
> Minor issues:
>    Why is the example if section 4 (and others later on) described
> as
> "non-normative"?  Is it incomplete?  incorrect?  An example is, by
> definition, not a full specification.  The language seems designed to
> reduce the value of the example.  I would recommend removing all the
> "non-normative" notes from the examples.  They are clearly stated to
> be examples.
>=20
> Nits/editorial comments:
>=20
>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


--Apple-Mail=_D4DDE6F9-30B0-4A43-B8EB-E8B1E3CFDC3A
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-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJYpZNEAAoJEM80gCTQU46q9qgQALAqVO+Fq3ngC7gNtrtIL6KY
0rJ3MRhLGdE5MzXP2c2Gb749J2BBlaRuMHb0uVRV51Lg1b9/LjmzF+6LSC/gDvlT
x4+sqQM6ldvlBJ92UxznzIWPIrEoxM9InDU3Qh1GohEqgw0+zcBshwtyLI0By/yr
yORUMyXZMNxxfrFAS3LJ8Wt3XWD8HA1OYrWYlHWygFj+UzTYlol/fZVOeP/LQuna
wgijEUxZ3X+xz6iG/prbM8vKrxTGPFLP4jIam8wAdswDX+iqi7f61zNpHiHkdbnR
RF6BeJd1A4Prf6v0HxN6uHmFGBb8RxbdLNFHGbmKrvyN6bJal8iGZ304RbUNjOuX
qYiGJGA+YHetJOs27Krerd77Dt0ccKsfaGZ4P3vTe4MWeiaveb63DUaY3pEeJpP0
iaIDziBZaUp3yLrawFVTIqwQxsUzEF3b+z7gX/anZNGv18dIjP/5491lGSN3wJVR
lQln/vAeiQb3kULFpN2jDd/MHlY8xhTWlvcxpSSxc0+RYrnXtTjiOTFT9PrVBac5
22apTzkrNe/yGNfMV9OigKQmPact/JXxYiyL6uMm+8Ifdhb/zZkVBcFukAoCVZRt
pdN4aWQV7wmb89gBR6DdJpSxodIg4NJnhSgkBs/J2XJlC5rnJopCIKoG8ftQI9PV
nhiHUiHVN3qTs9qHMC/j
=jkDx
-----END PGP SIGNATURE-----

--Apple-Mail=_D4DDE6F9-30B0-4A43-B8EB-E8B1E3CFDC3A--


From nobody Thu Feb 16 14:44:50 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E8D129526 for ; Thu, 16 Feb 2017 14:44:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtJ29oj3F82o for ; Thu, 16 Feb 2017 14:44:44 -0800 (PST)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 A36CB126B6D for ; Thu, 16 Feb 2017 14:44:44 -0800 (PST)
Received: by mail-pg0-x230.google.com with SMTP id v184so9614899pgv.3 for ; Thu, 16 Feb 2017 14:44:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version; bh=HQlPzf3W6zUCj5ct75dtswi7BWQ+qu2/4IKe9SCC3UU=; b=TmD/KzH7EKJ50/2ghHBSzGrxnsE0Kwi9VTzvPvQa5G/FM4LiglN068UpaCN7ZZ8chG yyPbJRUA8jZQBNyc2WiXyQ0ScxEEdiF2aU1hbUys2z39hyMCbnbhJXW8gVtW9rB3DZM8 8qLFNUq7s/mUNgVPvHxkdFTVnKdelKwHyrvTu2Ldli7pDvPCSebkk+XAEXWbmwev0JGj Bet/OXwuFJ3SYvbHS3SLeHW6PgptH3zGsjVzen3pi1BJC8jC8EYtyXImc/z0ti4TGHUm 6cDde4VSR6qPS/m6uq+2VhcMhwD+ZPYS2HaJc6/Yu4p5y1kffqGQHMRv4L9Dk6XmWjH6 9zsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=HQlPzf3W6zUCj5ct75dtswi7BWQ+qu2/4IKe9SCC3UU=; b=XAilIn961wu9RoxSFyOHbM8yZFsCs2hLJGTaK3rMtYlUqss/cGlok1aghmyL/HUisy ttFpqrNVghJ4eEJY3iNs6mWRyUUwRT3nampHu97isRIyFJOidlfPGnlYHEEH7FAzVayL H3wob13zvKqwT9iqo/yCjS/72phwZiq7B+EXENhueDm7ZH8y/pUw263+Kxxvne5gae5J RPTq7ue1RjXSF8eSGbSdSjh0iNZpgz/0qPKcUkPyck3QcHNRAKsQDWGVO3jFrjxNAcYq su+eMkMh5qE1xRKOqU87yTlJytDtoOaWtXgnIy8CKJxH+npD6Nzn6GbeLf2E30K6TaSR FmfQ==
X-Gm-Message-State: AMke39muLdskNKWRdFNaZ/vhE426uNW6/RD6wv1y5nTYftlbRrpwssxMo/bgIqElzC1VSlLF
X-Received: by 10.99.226.83 with SMTP id y19mr5847706pgj.34.1487285083918; Thu, 16 Feb 2017 14:44:43 -0800 (PST)
Received: from heembo.local ([2605:e000:112b:c167:9cf4:1bf2:7245:51bb]) by smtp.googlemail.com with ESMTPSA id u24sm15484208pfi.25.2017.02.16.14.44.42 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 14:44:43 -0800 (PST)
To: OAuth WG 
From: Jim Manico 
Message-ID: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com>
Date: Thu, 16 Feb 2017 12:44:42 -1000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------603A028C8258F4716A79857C"
Archived-At: 
Subject: [OAUTH-WG] Google's use of Implicit Grant Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 22:44:46 -0000

This is a multi-part message in MIME format.
--------------603A028C8258F4716A79857C
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hello Folks,

I noticed that Google supports the OAuth 2 Implicit flow for third-party
JavaScript applications.

https://developers.google.com/identity/protocols/OAuth2UserAgent

Isn't this generally discouraged from a security POV? *Is there a better
OAuth 2 flow for third party SPA applications?*

Aloha,

-- 
Jim Manico
Manicode Security
https://www.manicode.com


--------------603A028C8258F4716A79857C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
Hello Folks,

    
I noticed that Google supports the OAuth 2 Implicit flow for
      third-party JavaScript applications.

    
https://developers.google.com/identity/protocols/OAuth2UserAgent

    
Isn't this generally discouraged from a security POV? Is
        there a better OAuth 2 flow for third party SPA applications?

    

    Aloha,

    
-- 
Jim Manico
Manicode Security
https://www.manicode.com

  


--------------603A028C8258F4716A79857C--


From nobody Thu Feb 16 15:13:42 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2D4129485 for ; Thu, 16 Feb 2017 15:13:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiHeonZz3skd for ; Thu, 16 Feb 2017 15:13:40 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3583312944E for ; Thu, 16 Feb 2017 15:13:40 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ECC077E9E0 for ; Thu, 16 Feb 2017 23:13:40 +0000 (UTC)
Received: from Williams-MacBook-Pro.local (vpn-234-21.phx2.redhat.com [10.3.234.21]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1GNDe8g024540 for ; Thu, 16 Feb 2017 18:13:40 -0500
To: oauth@ietf.org
References: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com>
From: Bill Burke 
Message-ID: <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com>
Date: Thu, 16 Feb 2017 18:13:38 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com>
Content-Type: multipart/alternative; boundary="------------3CBF49A545BE0997C6BB9517"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 16 Feb 2017 23:13:40 +0000 (UTC)
Archived-At: 
Subject: Re: [OAUTH-WG] Google's use of Implicit Grant Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Feb 2017 23:13:41 -0000

This is a multi-part message in MIME format.
--------------3CBF49A545BE0997C6BB9517
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

For our IDP [1], our javascript library uses the auth code flow, but 
requires a public client, redirect_uri validation, and also does CORS 
checks and processing.  We did not like Implicit Flow because

1) access tokens would be in the browser history

2) short lived access tokens (seconds or minutes) would require a 
browser redirect

I'd be really curious to hear other's thoughts though.

[1] http://keycloak.org




On 2/16/17 5:44 PM, Jim Manico wrote:
>
> Hello Folks,
>
> I noticed that Google supports the OAuth 2 Implicit flow for 
> third-party JavaScript applications.
>
> https://developers.google.com/identity/protocols/OAuth2UserAgent
>
> Isn't this generally discouraged from a security POV? *Is there a 
> better OAuth 2 flow for third party SPA applications?*
>
> Aloha,
> -- 
> Jim Manico
> Manicode Security
> https://www.manicode.com
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------3CBF49A545BE0997C6BB9517
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
For our IDP [1], our javascript library uses the auth code flow,
      but requires a public client, redirect_uri validation, and also
      does CORS checks and processing.  We did not like Implicit Flow
      because

    
1) access tokens would be in the browser history

    
2) short lived access tokens (seconds or minutes) would require a
      browser redirect

    
I'd be really curious to hear other's thoughts though.

    

    
[1] http://keycloak.org

    


    

    


    

    

    
On 2/16/17 5:44 PM, Jim Manico wrote:

    

    

      
      
Hello Folks,

      
I noticed that Google supports the OAuth 2 Implicit flow for
        third-party JavaScript applications.

      
https://developers.google.com/identity/protocols/OAuth2UserAgent

      
Isn't this generally discouraged from a security POV? Is
          there a better OAuth 2 flow for third party SPA applications?

      

      Aloha,

      
-- 
Jim Manico
Manicode Security
https://www.manicode.com

      

      

      

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


    

    

  


--------------3CBF49A545BE0997C6BB9517--


From nobody Thu Feb 16 18:22:53 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF111297CF for ; Thu, 16 Feb 2017 18:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poVlX112MnB0 for ; Thu, 16 Feb 2017 18:22:50 -0800 (PST)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 4CFFA129463 for ; Thu, 16 Feb 2017 18:22:50 -0800 (PST)
Received: by mail-it0-x235.google.com with SMTP id h10so3697430ith.1 for ; Thu, 16 Feb 2017 18:22:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VX1HWz8jq6XBBQcYX1EHCf0a6kDqk4rKFrlAXReEP/w=; b=JqyLbHu3U4VlXbmc8ClBofR931mrBA7vwWTpp9M3bcWOTuqffWFQ2yz1DhUgI/AN3t RO1WhpeQUGsaUx9S81MKawcl/6DulZRHXy7ur2wIgjIjnVVV/w8cMAGEgku1Uy7YDOSu DdMte7HsdaIYbYBvkAgx9iDiIhbP7xhU4TUcJKWEOpkUC7/uE4H5lls/KzT9OIlWcl1V hseh+onmG+eOoRSl0MJDgWjEfe+6nw+cKQmG2Xm8q1th6h7VWSnfYRUpaSyO2zhMNCtg 7+i0vnCLjmthduaeooi4y5cJC9WXGznuc5loVTxn/BgnIaGHRF+26C0VsWpevxwX4tV1 mywQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VX1HWz8jq6XBBQcYX1EHCf0a6kDqk4rKFrlAXReEP/w=; b=i8g5muk30rT66qDy/K+DupPcajtg/XTOL8N7yRV61XfW6cTI+0soeCEEDPcmlb5ttm PULw94XYNlSUhLQVpUcSgH9HyjSaeUuSDVhuxPrCAg4D+k1L3e/d060zcKQmZMokeTrf a474oCqTpIlWp+vW4pKuInY+RLL4GcTYnXh6gFNKsB66JrGTwSCBHTCrHknyili9TPTu dsbtoJvnhyiDfDCVvHSWBO8Ngl+YFgmrPnZw4C2VF4ThworQ7pZwTdmqpmmkNow7Luu2 8Y/nczhO3tg3X92r+CFEVhn3ZcoP7UMOohrrD3sAUuz1jSdfi7TK5X/lNm9GXGQo12tC Sd5A==
X-Gm-Message-State: AMke39nQSr7gjmR1NQFoXmAIRdAuV1OJbFVsmM8nRHpz2A+ymXBF2RBXDd8RtRtM5K3DidR0WRlN/mLN/GLhiQ==
X-Received: by 10.107.15.167 with SMTP id 39mr4798909iop.204.1487298169342; Thu, 16 Feb 2017 18:22:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.168.221 with HTTP; Thu, 16 Feb 2017 18:22:28 -0800 (PST)
In-Reply-To: <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com>
References: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com> <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com>
From: Josh Mandel 
Date: Thu, 16 Feb 2017 21:22:28 -0500
Message-ID: 
To: Bill Burke 
Content-Type: multipart/alternative; boundary=001a113d3af80f16a80548b0974c
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Google's use of Implicit Grant Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 02:22:52 -0000

--001a113d3af80f16a80548b0974c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We've taken a similar approach for SMART Health IT [1], using the code flow
for public clients to support in-browser apps, and <1h token lifetime. (We
also allow these public clients to request a limited-duration refresh token
by asking for an "online_access" scope; these refresh tokens stop working
when the user's session with the AS ends =E2=80=94 useful in systems where =
that
session concept is meaningful.)

  -Josh

1. http://docs.smarthealthit.org/authorization/

On Thu, Feb 16, 2017 at 6:13 PM, Bill Burke  wrote:

> For our IDP [1], our javascript library uses the auth code flow, but
> requires a public client, redirect_uri validation, and also does CORS
> checks and processing.  We did not like Implicit Flow because
>
> 1) access tokens would be in the browser history
>
> 2) short lived access tokens (seconds or minutes) would require a browser
> redirect
>
> I'd be really curious to hear other's thoughts though.
>
> [1] http://keycloak.org
>
>
>
>
> On 2/16/17 5:44 PM, Jim Manico wrote:
>
> Hello Folks,
>
> I noticed that Google supports the OAuth 2 Implicit flow for third-party
> JavaScript applications.
>
> https://developers.google.com/identity/protocols/OAuth2UserAgent
>
> Isn't this generally discouraged from a security POV? *Is there a better
> OAuth 2 flow for third party SPA applications?*
> Aloha,
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a113d3af80f16a80548b0974c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


We've taken a similar approach for SMART Health IT [1]=
, using the code flow for public clients to support in-browser apps, and &l=
t;1h token lifetime. (We also allow these public clients to request a limit=
ed-duration refresh token by asking for an "online_access" scope;=
 these refresh tokens stop working when the user's session with the AS =
ends =E2=80=94 useful in systems where that session concept is meaningful.)=



On Thu, Feb 16, 2017 at 6:13 PM, Bill Burke=
 <bburke@redhat.com> wrote:

    
For our IDP [1], our javascript library uses the auth code flow,
      but requires a public client, redirect_uri validation, and also
      does CORS checks and processing.=C2=A0 We did not like Implicit Flow
      because

    
1) access tokens would be in the browser history

    
2) short lived access tokens (seconds or minutes) would require a
      browser redirect

    
I'd be really curious to hear other's thoughts though.

    

    
[1] http://keycloak=
.org

    


    

    


    

    

    
On 2/16/17 5:44 PM, Jim Manico wrote:

    

    

     =20
      
Hello Folks,

      
I noticed that Google supports the OAuth 2 Implicit flow for
        third-party JavaScript applications.

      
https://developers.google.com/identity/pro=
tocols/OAuth2UserAgent

      
Isn't this generally discouraged from a security POV? Is
          there a better OAuth 2 flow for third party SPA applications?=


      

      Aloha,

      
--=20
Jim Manico
Manicode Security
https://www.manicode.=
com

      

      

      

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


    

    

  



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





--001a113d3af80f16a80548b0974c--


From nobody Fri Feb 17 08:03:59 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C3112944D for ; Fri, 17 Feb 2017 08:03:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level: 
X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4nNy1kRnf_2 for ; Fri, 17 Feb 2017 08:03:56 -0800 (PST)
Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D305127071 for ; Fri, 17 Feb 2017 08:03:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1487347435; x=1518883435; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=OzhPpuqs/GLG1zRLbhNeqUzthXwxEejg1dRS3pwC+Y8=; b=xEDPFIMoqAhQXa9QXOI5vUsuO7UkXk01PK1+mDiMoEj0mBBDoBjkzmcg w6cA8Dgigxzro536i1K4DTrLV2/sGpmvpQEfEwWhYn+ZIN6a17HcCgT+P rLx29WzohkEaK7M+f2/TsMIpEbLoCOcqRjNreafdBLJNTIqlm/F8rDDeA pgbt+otLmrlSkk0Ie9WVHiILhgZzY7yXVvbeYFLg2JHuEP6/rjF5Tpplc AL86CZxfyVOQi7AbXQ/glmY8/96YYNVvqkyi0NMbLzpTNKQIv2Cdu3dWT xEYriwLChVbC9P8ilO5eUWJsfMu7TWQA9pvNK9uFwsU4FLZiQnsvtfa6k w==;
Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 17 Feb 2017 17:03:53 +0100
X-IronPort-AV: E=Sophos;i="5.35,172,1484002800";  d="scan'208,217";a="621113027"
Received: from he105715.emea1.cds.t-internal.com ([10.169.118.51]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 17 Feb 2017 17:03:53 +0100
Received: from HE105717.EMEA1.cds.t-internal.com (10.169.118.53) by HE105715.emea1.cds.t-internal.com (10.169.118.51) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 17 Feb 2017 17:03:53 +0100
Received: from HE105717.EMEA1.cds.t-internal.com ([fe80::5881:9115:c037:89f8]) by HE105717.emea1.cds.t-internal.com ([fe80::5881:9115:c037:89f8%26]) with mapi id 15.00.1263.000; Fri, 17 Feb 2017 17:03:52 +0100
From: 
To: , 
Thread-Topic: [OAUTH-WG] Google's use of Implicit Grant Flow
Thread-Index: AQHSiKZY8rBjj2HMMkuyqR4U8Rqi96FsMosAgAEqb+A=
Date: Fri, 17 Feb 2017 16:03:52 +0000
Message-ID: <600a2fe3fbc147588baedb557e6e5938@HE105717.emea1.cds.t-internal.com>
References: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com> <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com>
In-Reply-To: <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.157.116.64]
Content-Type: multipart/alternative; boundary="_000_600a2fe3fbc147588baedb557e6e5938HE105717emea1cdstintern_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] Google's use of Implicit Grant Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 16:03:58 -0000

--_000_600a2fe3fbc147588baedb557e6e5938HE105717emea1cdstintern_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Same for Deutsche Telekom. Our javascript clients also use code flow with C=
ORS processing and of course redirect_uri validation.

Best regards

Sebastian

Von: OAuth [mailto:oauth-bounces@ietf.org] Im Auftrag von Bill Burke
Gesendet: Freitag, 17. Februar 2017 00:14
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] Google's use of Implicit Grant Flow


For our IDP [1], our javascript library uses the auth code flow, but requir=
es a public client, redirect_uri validation, and also does CORS checks and =
processing.  We did not like Implicit Flow because

1) access tokens would be in the browser history

2) short lived access tokens (seconds or minutes) would require a browser r=
edirect

I'd be really curious to hear other's thoughts though.

[1] http://keycloak.org





On 2/16/17 5:44 PM, Jim Manico wrote:

Hello Folks,

I noticed that Google supports the OAuth 2 Implicit flow for third-party Ja=
vaScript applications.

https://developers.google.com/identity/protocols/OAuth2UserAgent

Isn't this generally discouraged from a security POV? Is there a better OAu=
th 2 flow for third party SPA applications?
Aloha,


--

Jim Manico

Manicode Security

https://www.manicode.com




_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth


--_000_600a2fe3fbc147588baedb557e6e5938HE105717emea1cdstintern_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Same for Deutsche Telekom=
.
Our javascript clients als=
o use code flow with CORS processing and of course redirect_uri validation.=



 =
;


Best regar=
ds


 =
;


Sebastian<=
o:p>


 =
;






Von: OAuth [mailto:oauth-bounces@ietf.org]
Im Auftrag von Bill Burke

Gesendet: Freitag, 17. Februar 2017 00:14

An: oauth@ietf.org

Betreff: Re: [OAUTH-WG] Google's use of Implicit Grant Flow






 


For our IDP [1], our javascript library uses the auth code flow, but req=
uires a public client, redirect_uri validation, and also does CORS checks a=
nd processing.  We did not like Implicit Flow because


1) access tokens would be in the browser history


2) short lived access tokens (seconds or minutes) would require a browse=
r redirect


I'd be really curious to hear other's thoughts though.


[1] http://keycloak.org

 


 


 




On 2/16/17 5:44 PM, Jim Manico wrote:






Hello Folks,


I noticed that Google supports the OAuth 2 Implicit flow for third-party=
 JavaScript applications.


https://developers.google.com/identity/protocols/OAuth2UserAgent


Isn't this generally discouraged from a security POV? Is there a bett=
er OAuth 2 flow for third party SPA applications?


Aloha,






-- 


Jim Manico


Manicode Security


https://www.manicode.com=












_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth




 






--_000_600a2fe3fbc147588baedb557e6e5938HE105717emea1cdstintern_--


From nobody Fri Feb 17 09:40:33 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B38E1295F4 for ; Fri, 17 Feb 2017 09:40:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3A8WtIi91Sw for ; Fri, 17 Feb 2017 09:40:29 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 A58C51295D3 for ; Fri, 17 Feb 2017 09:40:29 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id 189so15022214pfu.3 for ; Fri, 17 Feb 2017 09:40:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=l+C6sA2ycyWmw7GwTrObejs+2r7l7M82BTcr2c9iHVI=; b=G7AFi/wZw58Xa5aruKUUMBYVESTX7yQER2EQJV2BGiquEHO/m5rasjXztRXMdFOMvU HAUKkuPjUzTHXDZVuHS4Y//Zct02WEJa3Emu18Nl9/aKKGDbscigzR8/fx3yYznp2Fgy 2vxL5WTzPAJ1HC/cWZ4kx8Kkia04ORUnh2JGnzMrlcutrCbCSQMpPtrPnPyFLusXi9F4 a/f6P/bGTPJZU/fTwuvk/9UWKPEq6vTeo7vnBZ0xhXTuA4rBjSE7tA3gUJvrpEisNFhs t+JbTV2f7Yas2bXsFAu39h+7iFjKVuaKTfPwtCa+Q2DaDDFzFzI+EV1sSR0GvI14ciKQ CLgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=l+C6sA2ycyWmw7GwTrObejs+2r7l7M82BTcr2c9iHVI=; b=DX18qT5Aj2VIgiwMscRrfhTGjvA2ZOUw4+MU6RlypbcuokPmdCuvGSz6Cu3b4kkkhs lIOoiqVevXGQrAk3GlkJOUKi7yWAZ2OZVTwdHRUa6M0mwQFgBjmeGsOzHERftnSAHIpM fub1aW3bvQAahQwWn1op2UQcYFgZ7Az8+kOPaQ6Z2t75KbL7elc+43KyBaPIqbLSKu8/ 09DYXXABRWNLKtiNheSDfwolAt5uVwSQjn/UdxI5Nh+gBfIdQoUn5Kctz39CPN6SFFt5 GLCugGzZHRVtYxN8Is2iAKhCc47Uxljt2tcAD0fNXnghIacdsMToHNl0Ny4+szBW/my+ 1n7Q==
X-Gm-Message-State: AMke39lWQJEQicvVwr/eHPLQhv1Dv0UzY37KfHxUIa1pG+MgmSsj93U/9d7O4k9FNf6NCE0I
X-Received: by 10.99.108.74 with SMTP id h71mr11400805pgc.99.1487353229132; Fri, 17 Feb 2017 09:40:29 -0800 (PST)
Received: from heembo.local ([2605:e000:112b:c167:3519:b801:95b1:4955]) by smtp.googlemail.com with ESMTPSA id e2sm20861131pga.61.2017.02.17.09.40.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 09:40:27 -0800 (PST)
To: Sebastian.Ebling@telekom.de, bburke@redhat.com, oauth@ietf.org
References: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com> <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com> <600a2fe3fbc147588baedb557e6e5938@HE105717.emea1.cds.t-internal.com>
From: Jim Manico 
Message-ID: <9f795a60-5345-61b6-356a-cc871164ba8d@manicode.com>
Date: Fri, 17 Feb 2017 07:40:25 -1000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <600a2fe3fbc147588baedb557e6e5938@HE105717.emea1.cds.t-internal.com>
Content-Type: multipart/alternative; boundary="------------817491028CB9E0D4B82C3911"
Archived-At: 
Subject: Re: [OAUTH-WG] Google's use of Implicit Grant Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 17:40:31 -0000

This is a multi-part message in MIME format.
--------------817491028CB9E0D4B82C3911
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Thank you to those answering my question on implicit for JS clients.

The responses so far seem to represent what the security world is
saying  about the implicit grant - keep away from it other than for a
few OIDC use cases.

Does anyone think it would be valuable to author a brief RFC to give
clear OAuth 2 recommendations for JavaScript client developers?

I mean - the OAuth 2 body of work just needs a few more RFC's, right? :)

Aloha, Jim



On 2/17/17 6:03 AM, Sebastian.Ebling@telekom.de wrote:
>
> Same for Deutsche Telekom. Our javascript clients also use code flow
> with CORS processing and of course redirect_uri validation.
>
>  
>
> Best regards
>
>  
>
> Sebastian
>
>  
>
> *Von:*OAuth [mailto:oauth-bounces@ietf.org] *Im Auftrag von *Bill Burke
> *Gesendet:* Freitag, 17. Februar 2017 00:14
> *An:* oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] Google's use of Implicit Grant Flow
>
>  
>
> For our IDP [1], our javascript library uses the auth code flow, but
> requires a public client, redirect_uri validation, and also does CORS
> checks and processing.  We did not like Implicit Flow because
>
> 1) access tokens would be in the browser history
>
> 2) short lived access tokens (seconds or minutes) would require a
> browser redirect
>
> I'd be really curious to hear other's thoughts though.
>
> [1] http://keycloak.org
>
>  
>
>  
>
>  
>
> On 2/16/17 5:44 PM, Jim Manico wrote:
>
>     Hello Folks,
>
>     I noticed that Google supports the OAuth 2 Implicit flow for
>     third-party JavaScript applications.
>
>     https://developers.google.com/identity/protocols/OAuth2UserAgent
>
>     Isn't this generally discouraged from a security POV? *Is there a
>     better OAuth 2 flow for third party SPA applications?*
>
>     Aloha,
>
>     -- 
>
>     Jim Manico
>
>     Manicode Security
>
>     https://www.manicode.com
>
>
>
>
>     _______________________________________________
>
>     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

-- 
Jim Manico
Manicode Security
https://www.manicode.com


--------------817491028CB9E0D4B82C3911
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thank you to those answering my question on implicit for JS
      clients. 

    

    
The responses so far seem to represent what the security world is
      saying  about the implicit grant - keep away from it other than
      for a few OIDC use cases.

    

    
Does anyone think it would be valuable to author a brief RFC to
      give clear OAuth 2 recommendations for JavaScript client
      developers?

    
I mean - the OAuth 2 body of work just needs a few more RFC's,
      right? :)

    
Aloha, Jim

    

    


    

    

    
On 2/17/17 6:03 AM,
      Sebastian.Ebling@telekom.de wrote:

    

    

      
      
      
      

        
Same
            for Deutsche Telekom.
          Our javascript clients also use code flow with
            CORS processing and of course redirect_uri validation.

        
 

        
Best regards

        
 

        
Sebastian

        
 

        

          

            
Von:
                OAuth [mailto:oauth-bounces@ietf.org]
                Im Auftrag von Bill Burke

                Gesendet: Freitag, 17. Februar 2017 00:14

                An: oauth@ietf.org

                Betreff: Re: [OAUTH-WG] Google's use of Implicit
                Grant Flow

          

        

        
 

        
For our IDP [1], our javascript library uses the auth code
          flow, but requires a public client, redirect_uri validation,
          and also does CORS checks and processing.  We did not like
          Implicit Flow because

        
1) access tokens would be in the browser history

        
2) short lived access tokens (seconds or minutes) would
          require a browser redirect

        
I'd be really curious to hear other's thoughts though.

        
[1] http://keycloak.org

        
 

        
 

        
 

        

          
On 2/16/17 5:44 PM, Jim Manico wrote:

        

        

          
Hello Folks,

          
I noticed that Google supports the OAuth 2 Implicit flow
            for third-party JavaScript applications.

          
https://developers.google.com/identity/protocols/OAuth2UserAgent

          
Isn't this generally discouraged from a security POV? Is
              there a better OAuth 2 flow for third party SPA
              applications?

          
Aloha,

            

            

          
-- 

          
Jim Manico

          
Manicode Security

          
https://www.manicode.com

          


            

            

            

          
_______________________________________________

          
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


    

    

    
-- 
Jim Manico
Manicode Security
https://www.manicode.com

  


--------------817491028CB9E0D4B82C3911--


From nobody Fri Feb 17 09:43:23 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A96129664 for ; Fri, 17 Feb 2017 09:43:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBqFDziAJr04 for ; Fri, 17 Feb 2017 09:43:16 -0800 (PST)
Received: from mx0b-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 B3271129655 for ; Fri, 17 Feb 2017 09:43:16 -0800 (PST)
Received: from pps.filterd (m0074409.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v1HHfJxh015857 for ; Fri, 17 Feb 2017 11:43:16 -0600
Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by mx0a-0019e102.pphosted.com with ESMTP id 28p3t28d2x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 17 Feb 2017 11:43:16 -0600
Received: by mail-oi0-f69.google.com with SMTP id u143so56295859oif.1 for ; Fri, 17 Feb 2017 09:43:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VuNDckd2hmt4X1E267XA272kMrq0EhSN6TbVFVQziaM=; b=bmmJADFHiGTEJp6bsKrK93IBR94qKqIumvBQ2JkQxwgwSEtOrsGKcwm0fZNHaSAFDs RQai6RXOxdrYPTE1uKGflnBmZGx2c/OQHMsP9LChxNELA82YG8aL9DDn5zL8dowNEdjS Xjq1An12Hydyd/0CXgt9J/Sv/JBKKck8nb116RnZQsmeIj3EcYix4MvKE5vOTmlGYGE3 n+BoxYujVRdygL9VBjbv3HBvOb7Vey6SbNoNZq6xoe6clhsLCmXZntTikkHJN6RAwF8O RTG06guJT5wgCBLOVjqfA92a1vJW9v455xInDwh9aV+hyou/RcnAybCpX/WyHR3JiXwl lp0w==
X-Gm-Message-State: AMke39lootK+4ixzSexUlyq6yO/h1nLTP570o6oeM+riclZjbp8SD1bYvo+hra5sgfDjYK6E16hCwp4LkctBur8QyoMDzEadS7Kg+Uh+ag80sKvHb68A0aQDTBjwNeNePL4hk0vs1uEG0f4E
X-Received: by 10.157.29.182 with SMTP id y51mr4514879otd.256.1487353395181; Fri, 17 Feb 2017 09:43:15 -0800 (PST)
X-Received: by 10.157.29.182 with SMTP id y51mr4514875otd.256.1487353394998; Fri, 17 Feb 2017 09:43:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.74.85.85 with HTTP; Fri, 17 Feb 2017 09:42:54 -0800 (PST)
In-Reply-To: <9f795a60-5345-61b6-356a-cc871164ba8d@manicode.com>
References: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com> <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com> <600a2fe3fbc147588baedb557e6e5938@HE105717.emea1.cds.t-internal.com> <9f795a60-5345-61b6-356a-cc871164ba8d@manicode.com>
From: Adam Lewis 
Date: Fri, 17 Feb 2017 11:42:54 -0600
Message-ID: 
To: Jim Manico 
Content-Type: multipart/alternative; boundary=001a1141fb8ac3c7540548bd728e
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702170164
Archived-At: 
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Google's use of Implicit Grant Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 17:43:20 -0000

--001a1141fb8ac3c7540548bd728e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1000

We are currently going through internal turmoil over the usage of implicit
grant for ua-based apps.  The webapp case is well understood and the WG has
work in progress to define best practices for native apps.  Having one for
ua-based apps would be HUGELY beneficial



On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico  wrote:

> Thank you to those answering my question on implicit for JS clients.
>
> The responses so far seem to represent what the security world is saying
> about the implicit grant - keep away from it other than for a few OIDC us=
e
> cases.
>
> Does anyone think it would be valuable to author a brief RFC to give clea=
r
> OAuth 2 recommendations for JavaScript client developers?
>
> I mean - the OAuth 2 body of work just needs a few more RFC's, right? :)
>
> Aloha, Jim
>
>
>
> On 2/17/17 6:03 AM, Sebastian.Ebling@telekom.de wrote:
>
> Same for Deutsche Telekom. Our javascript clients also use code flow with
> CORS processing and of course redirect_uri validation.
>
>
>
> Best regards
>
>
>
> Sebastian
>
>
>
> *Von:* OAuth [mailto:oauth-bounces@ietf.org ] *Im
> Auftrag von *Bill Burke
> *Gesendet:* Freitag, 17. Februar 2017 00:14
> *An:* oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] Google's use of Implicit Grant Flow
>
>
>
> For our IDP [1], our javascript library uses the auth code flow, but
> requires a public client, redirect_uri validation, and also does CORS
> checks and processing.  We did not like Implicit Flow because
>
> 1) access tokens would be in the browser history
>
> 2) short lived access tokens (seconds or minutes) would require a browser
> redirect
>
> I'd be really curious to hear other's thoughts though.
>
> [1] http://keycloak.org
> 
>
>
>
>
>
>
>
> On 2/16/17 5:44 PM, Jim Manico wrote:
>
> Hello Folks,
>
> I noticed that Google supports the OAuth 2 Implicit flow for third-party
> JavaScript applications.
>
> https://developers.google.com/identity/protocols/OAuth2UserAgent
> 
>
> Isn't this generally discouraged from a security POV? *Is there a better
> OAuth 2 flow for third party SPA applications?*
>
> Aloha,
>
> --
>
> Jim Manico
>
> Manicode Security
>
> https://www.manicode.com 
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth 
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th 
>
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com 
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a1141fb8ac3c7540548bd728e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1000

We are currently going through in=
ternal turmoil over the usage of implicit grant for ua-based apps.=C2=A0 Th=
e webapp case is well understood and the WG has work in progress to define =
best practices for native apps.=C2=A0 Having one for ua-based apps would be=
 HUGELY beneficial



On Fri, Feb 17, 2017 at 11:40 AM=
, Jim Manico <jim@manicode.com> wrote:

 =20
   =20
 =20
  

    
Thank you to those answering my question on implicit for JS
      clients. 

    

    
The responses so far seem to represent what the security world is
      saying=C2=A0 about the implicit grant - keep away from it other than
      for a few OIDC use cases.

    

    
Does anyone think it would be valuable to author a brief RFC to
      give clear OAuth 2 recommendations for JavaScript client
      developers?

    
I mean - the OAuth 2 body of work just needs a few more RFC's,
      right? :)

    
Aloha, Jim

    

    


    

    

    
On 2/17/17 6:03 AM,
      Sebastian.Ebling@teleko=
m.de wrote:

    

    

     =20
     =20
     =20
      

        
Same
            for Deutsche Telekom.
          Our javascript c=
lients also use code flow with
            CORS processing and of course redirect_uri validation.

        
=C2=A0

        
Be=
st regards

        
=C2=A0

        
Se=
bastian

        
=C2=A0

        

          

            
Von:
                OAuth [mailto:oauth-b=
ounces@ietf.org]
                Im Auftrag von Bill Burke

                Gesendet: Freitag, 17. Februar 2017 00:14

                An: oauth@ietf.org<=
/a>

                Betreff: Re: [OAUTH-WG] Google's use of Implicit
                Grant Flow

          

        

        
=C2=A0

        
For our IDP [1], our javascript library uses the auth code
          flow, but requires a public client, redirect_uri validation,
          and also does CORS checks and processing.=C2=A0 We did not like
          Implicit Flow because

        
1) access tokens would be in the browser history
        
2) short lived access tokens (seconds or minutes) would
          require a browser redirect

        
I'd be really curious to hear other's thoughts though.

        
[1] http://keycloak.org

        
=C2=A0

        
=C2=A0

        
=C2=A0

        

          
On 2/16/17 5:44 PM, Jim Manico wrote:

        

        

          
Hello Folks,

          
I noticed that Google supports the OAuth 2 Implicit flow
            for third-party JavaScript applications.

          
https://d=
evelopers.google.com/identity/protocols/OAuth2UserAgent

          
Isn't this generally discouraged from a security POV? I=
s
              there a better OAuth 2 flow for third party SPA
              applications?

          
Aloha,

            

            

          
-- 

          
Jim Manico

          
Manicode Security

          
https://www.manicode.com
          


            

            

            

          
_______________________________________________<=
u>

          
OAuth mailing list

          
OAuth@ie=
tf.org

          
https://www.ietf.org/mailman=
/listinfo/oauth

        

        
=C2=A0

      

      

      

      

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


    

    

    
--=20
Jim Manico
Manicode Security
https://w=
ww.manicode.com

  



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





--001a1141fb8ac3c7540548bd728e--


From nobody Fri Feb 17 10:02:57 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750AD129B08 for ; Fri, 17 Feb 2017 10:02:55 -0800 (PST)
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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GUrKsVoxueq for ; Fri, 17 Feb 2017 10:02:53 -0800 (PST)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 E0CD2129B0C for ; Fri, 17 Feb 2017 10:02:52 -0800 (PST)
Received: by mail-yw0-x232.google.com with SMTP id v200so26674325ywc.3 for ; Fri, 17 Feb 2017 10:02:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=mAki4waeNNr/sG/wNXYDcKlsTNwHm+DyZGamI/XOlxo=; b=OtzP+rcFapFu1pkYSPlq5jpKr7rS0dkIc4iTHLD5YaKCCcHB+KWpznnOLB80hVw5uK 7XL9PNW8qmQPt20BP0I9Kt77GTNvBI+fAPTl4Hzqnrb72oZgxEXlZf5wZJeaC3XcTDnt JP540tfB8GTN1+nEMeVGWuxRfLndvHocMzRifo7Ha8ijKB4X3YvQmAsS6NSeN9vmRSFl dicVlNCfgtKisCe9kbCYwTciGf3AA2qRFpbvr8Sgnq9PU7pgf+ujdZmD6M8QaKcURrL+ NpHsJA7fdzpS/WcupvF3ayEB/pWxynG1E1EaCM6/SkNypMyCjQugujksN3qz+0Y93Kg7 wvNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=mAki4waeNNr/sG/wNXYDcKlsTNwHm+DyZGamI/XOlxo=; b=SOcwI4CmMDx6Jbogbwf89AEwVfKDd2Nobw/V2wIKDoV46tGFfMyzLPNeLVdhqRhIbK facG4MQj8TAs3VU4WKZCz2lE3f2Swki1DF63t7JFzKH4r1zRciTtTaaLdhLc3IKlHDhZ ZXadYGyy5A5JoyBLlFJ8kO48tlo6BmTEGgXpWV1nPPVqznkGvDS15rt4PXo8QbdlqXr7 vThCj6V0Old6UMfMQhupDmTDOH9bleGzZ9tAQiDl+cC5NMa3MutGtco5Ym9ggfD9Z7xD HIb8CDeaphFDnd2tdrYu/1R7jFnPBuoPC1l2Y5B6YXPLLz26MmG29uKcwDuT3JbnZmuk b/4g==
X-Gm-Message-State: AMke39kx+D5UNq3F8zwp/vGLi6KlKI0iVvT/9Sx7jFmUZVSjrxxN9QZm9C2QwdYq2o1OhpxUiT4L0zJ5BkgJ1Q==
X-Received: by 10.129.117.214 with SMTP id q205mr6676109ywc.212.1487354572096;  Fri, 17 Feb 2017 10:02:52 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 17 Feb 2017 13:02:51 -0500
From: Dominick Baier 
In-Reply-To: 
References: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com> <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com> <600a2fe3fbc147588baedb557e6e5938@HE105717.emea1.cds.t-internal.com> <9f795a60-5345-61b6-356a-cc871164ba8d@manicode.com> 
X-Mailer: Airmail (397)
MIME-Version: 1.0
Date: Fri, 17 Feb 2017 13:02:51 -0500
Message-ID: 
To: Adam Lewis , Jim Manico 
Content-Type: multipart/alternative; boundary=001a1147f990ecf4fb0548bdb858
Archived-At: 
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Google's use of Implicit Grant Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 18:02:55 -0000

--001a1147f990ecf4fb0548bdb858
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Given a solid client library for JS, I think implicit flow is OK to use.

But I agree that there are many =E2=80=9Chome grown=E2=80=9D implementation=
 out there that
are not secure - and the necessary JS code to write a good client is not
necessarily the =E2=80=9Cpit of success=E2=80=9D.

You should give this lib a go (it=E2=80=99s also a certified RP):

https://github.com/IdentityModel/oidc-client-js

Many people argue that handling the protocol and crypto pieces in JS is
problematic (and I agree if no proper lib is used for that) - but at then
end of the day the access token will end up in the browser - and a sloppy
developer (e.g. not using CSP) will always write bad code that might lead
to leaking a token.

-------
Dominick Baier

On 17 February 2017 at 18:43:25, Adam Lewis (
adam.lewis@motorolasolutions.com) wrote:

+1000

We are currently going through internal turmoil over the usage of implicit
grant for ua-based apps.  The webapp case is well understood and the WG has
work in progress to define best practices for native apps.  Having one for
ua-based apps would be HUGELY beneficial



On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico  wrote:

> Thank you to those answering my question on implicit for JS clients.
>
> The responses so far seem to represent what the security world is saying
> about the implicit grant - keep away from it other than for a few OIDC us=
e
> cases.
>
> Does anyone think it would be valuable to author a brief RFC to give clea=
r
> OAuth 2 recommendations for JavaScript client developers?
>
> I mean - the OAuth 2 body of work just needs a few more RFC's, right? :)
>
> Aloha, Jim
>
>
>
> On 2/17/17 6:03 AM, Sebastian.Ebling@telekom.de wrote:
>
> Same for Deutsche Telekom. Our javascript clients also use code flow with
> CORS processing and of course redirect_uri validation.
>
>
>
> Best regards
>
>
>
> Sebastian
>
>
>
> * Von:* OAuth [mailto:oauth-bounces@ietf.org ] *I=
m
> Auftrag von* Bill Burke
> *Gesendet:* Freitag, 17. Februar 2017 00:14
> *An:* oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] Google's use of Implicit Grant Flow
>
>
>
> For our IDP [1], our javascript library uses the auth code flow, but
> requires a public client, redirect_uri validation, and also does CORS
> checks and processing.  We did not like Implicit Flow because
>
> 1) access tokens would be in the browser history
>
> 2) short lived access tokens (seconds or minutes) would require a browser
> redirect
>
> I'd be really curious to hear other's thoughts though.
>
> [1] http://keycloak.org
> 
>
>
>
>
>
>
>
> On 2/16/17 5:44 PM, Jim Manico wrote:
>
> Hello Folks,
>
> I noticed that Google supports the OAuth 2 Implicit flow for third-party
> JavaScript applications.
>
> https://developers.google.com/identity/protocols/OAuth2UserAgent
> 
>
> Isn't this generally discouraged from a security POV? *Is there a better
> OAuth 2 flow for third party SPA applications?*
>
> Aloha,
>
> --
>
> Jim Manico
>
> Manicode Security
>
> https://www.manicode.com 
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth 
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th 
>
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com 
>
>
> _______________________________________________
> 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

--001a1147f990ecf4fb0548bdb858
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=

Given a solid client library for JS, I think impl=
icit flow is OK to use.=C2=A0

But I agree that there are many =E2=80=9Chome grown=E2=80=9D imple=
mentation out there that are not secure - and the necessary JS code to writ=
e a good client is not necessarily the =E2=80=9Cpit of success=E2=80=9D.

You should give this li=
b a go (it=E2=80=99s also a certified RP):

 

M=
any people argue that handling the protocol and crypto pieces in JS is prob=
lematic (and I agree if no proper lib is used for that) - but at then end o=
f the day the access token will end up in the browser - and a sloppy develo=
per (e.g. not using CSP) will always write bad code that might lead to leak=
ing a token.
 

-------
Dominick Baier
 
=

On 17 February 2017 at 18:43:25, Adam Lewis (adam.lewis@motorolasolutions.=
com) wrote:
 







+1000




We are currently going through internal turmoil over the usage
of implicit grant for ua-based apps.=C2=A0 The webapp case is well
understood and the WG has work in progress to define best practices
for native apps.=C2=A0 Having one for ua-based apps would be HUGELY
beneficial













On Fri, Feb 17, 2017 at 11:40 AM, Jim
Manico <jim@manicode.com> wrote:






Thank you to those answering my question on implicit for JS
clients.


The responses so far seem to represent what the security world
is saying=C2=A0 about the implicit grant - keep away from it other
than for a few OIDC use cases.


Does anyone think it would be valuable to author a brief RFC to
give clear OAuth 2 recommendations for JavaScript client
developers?


I mean - the OAuth 2 body of work just needs a few more RFC's,
right? :)


Aloha, Jim











On 2/17/17 6:03
AM, Sebastian.Ebling@telekom.=
de wrote:







Same for Deutsche Telekom. Our javascript clients also use code
flow with CORS processing and of course redirect_uri
validation.


=C2=A0


Best regar=
ds


=C2=A0


Sebastian<=
/span>


=C2=A0



=C2=A0


For our IDP [1], our javascript library uses the auth code flow,
but requires a public client, redirect_uri validation, and also
does CORS checks and processing.=C2=A0 We did not like Implicit
Flow because


1) access tokens would be in the browser history


2) short lived access tokens (seconds or minutes) would require
a browser redirect


I'd be really curious to hear other's thoughts though.


[1] http://keycloak.org


=C2=A0


=C2=A0


=C2=A0




On 2/16/17 5:44 PM, Jim Manico wrote:






Hello Folks,


I noticed that Google supports the OAuth 2 Implicit flow for
third-party JavaScript applications.


https://developers.=
google.com/identity/protocols/OAuth2UserAgent


Isn't this generally discouraged from a security POV? Is
there a better OAuth 2 flow for third party SPA
applications?


Aloha,




-- 


Jim Manico


Manicode Security


https://www.manicode.com









_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/list=
info/oauth


=C2=A0












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





-- =20
Jim Manico
Manicode Security
https://w=
ww.manicode.com







_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth










_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.iet=
f.org/mailman/listinfo/oauth



--001a1147f990ecf4fb0548bdb858--


From nobody Fri Feb 17 10:05:34 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D35129631 for ; Fri, 17 Feb 2017 10:05:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGCHYkpK910j for ; Fri, 17 Feb 2017 10:05:30 -0800 (PST)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 45282129B08 for ; Fri, 17 Feb 2017 10:05:30 -0800 (PST)
Received: by mail-it0-x22a.google.com with SMTP id g67so23404332itb.1 for ; Fri, 17 Feb 2017 10:05:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IibxqxLOjBTg6WVyU7qCfmYPT0dO9KuTtkKpaHJmZYQ=; b=F5czkaVoWl9BEFjS+vVPUNuGxQFecgwlLOU1g/aGnuIhI/+LFldyX2eQVgG8ITWKjc 4NnStitZyQD+qltqCodpIGJcCQWyYJSxQTxpxNtkKZKw0l+4Dr1vvVJQANFW6XmZRvKM ErF92RfeZmjaMGjYZZiZrdxZBgEBx3DPUpjhlv/z1e1RCrqzbxfeT9kZSultk/P1xkH1 eBMQsJDwrpd6xq++vtk4XhTrQMIL4+nyKQpRvkyfD6PpcMztTuogy5QY2Cee+T93SUGL MNniNVgYtt+yoJ52oIh6OkpJwrqQ22glfVjPbqKw3UUqiwEAPcBxPCPHzhMBCS7jVeL4 no2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IibxqxLOjBTg6WVyU7qCfmYPT0dO9KuTtkKpaHJmZYQ=; b=mMKvAoOdDiDMaDH4t8c6JYX/uxym4tZrt37bPJ9Q/EnTVAQsn5qGPXqvspRks7y9uO z8Sjre6094rH1eI6mqvyqr+WYRpTcdYUmX1aZ+cCoaMtSh0ChfMxS3AWWp24krHYuyFQ vVlDYkcFGrZtE8KS/Qa7rxTvX8/QHdztB5SZgdtgex7xAq+ccfob4kKwG1zOZMrsYz9d 2W0Du6cebuLKezG1jTunvb1ZtPWjXutgjQ2//0OIK6TBgdJbxjswnR5OJgbGTPZQU4Hy irxgflbU5snl8jK1iYgwtV1E7NmQdE15cCc/PCuJocY4MgalRNo/JzhOJntdlqpVNh+p YINg==
X-Gm-Message-State: AMke39nenqZcpIA1ns7PrF8oX3KLh/0t9UuKzfvK+Gb6ubTD15pl/aH9016aego6Jej5rw==
X-Received: by 10.107.14.78 with SMTP id 75mr7598791ioo.76.1487354729405; Fri, 17 Feb 2017 10:05:29 -0800 (PST)
Received: from mail-it0-f47.google.com (mail-it0-f47.google.com. [209.85.214.47]) by smtp.gmail.com with ESMTPSA id o26sm4984579ioi.4.2017.02.17.10.05.28 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 10:05:28 -0800 (PST)
Received: by mail-it0-f47.google.com with SMTP id g67so23403630itb.1 for ; Fri, 17 Feb 2017 10:05:28 -0800 (PST)
X-Received: by 10.107.200.70 with SMTP id y67mr7929341iof.73.1487354728394; Fri, 17 Feb 2017 10:05:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.183.81 with HTTP; Fri, 17 Feb 2017 10:05:27 -0800 (PST)
In-Reply-To: 
References: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com> <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com> <600a2fe3fbc147588baedb557e6e5938@HE105717.emea1.cds.t-internal.com> <9f795a60-5345-61b6-356a-cc871164ba8d@manicode.com>  
From: Aaron Parecki 
Date: Fri, 17 Feb 2017 10:05:27 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Dominick Baier 
Content-Type: multipart/alternative; boundary=94eb2c0c0b823dd51f0548bdc256
Archived-At: 
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Google's use of Implicit Grant Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 18:05:33 -0000

--94eb2c0c0b823dd51f0548bdc256
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Can you describe the aspects that make a JS client library "solid"? This is
what I think would be useful to see written up in a document like the
Native Apps one.

It's interesting to me that so many of you have independently opted to use
the auth code flow for Javascript apps. I think that's a sign that it's a
better recommendation than the implicit flow for JS apps.

----
Aaron Parecki
aaronparecki.com
@aaronpk 


On Fri, Feb 17, 2017 at 10:02 AM, Dominick Baier 
wrote:

> Given a solid client library for JS, I think implicit flow is OK to use.
>
> But I agree that there are many =E2=80=9Chome grown=E2=80=9D implementati=
on out there that
> are not secure - and the necessary JS code to write a good client is not
> necessarily the =E2=80=9Cpit of success=E2=80=9D.
>
> You should give this lib a go (it=E2=80=99s also a certified RP):
>
> https://github.com/IdentityModel/oidc-client-js
>
> Many people argue that handling the protocol and crypto pieces in JS is
> problematic (and I agree if no proper lib is used for that) - but at then
> end of the day the access token will end up in the browser - and a sloppy
> developer (e.g. not using CSP) will always write bad code that might lead
> to leaking a token.
>
> -------
> Dominick Baier
>
> On 17 February 2017 at 18:43:25, Adam Lewis (adam.lewis@motorolasolutions=
.
> com) wrote:
>
> +1000
>
> We are currently going through internal turmoil over the usage of implici=
t
> grant for ua-based apps.  The webapp case is well understood and the WG h=
as
> work in progress to define best practices for native apps.  Having one fo=
r
> ua-based apps would be HUGELY beneficial
>
>
>
> On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico  wrote:
>
>> Thank you to those answering my question on implicit for JS clients.
>>
>> The responses so far seem to represent what the security world is saying
>> about the implicit grant - keep away from it other than for a few OIDC u=
se
>> cases.
>>
>> Does anyone think it would be valuable to author a brief RFC to give
>> clear OAuth 2 recommendations for JavaScript client developers?
>>
>> I mean - the OAuth 2 body of work just needs a few more RFC's, right? :)
>>
>> Aloha, Jim
>>
>>
>>
>> On 2/17/17 6:03 AM, Sebastian.Ebling@telekom.de wrote:
>>
>> Same for Deutsche Telekom. Our javascript clients also use code flow
>> with CORS processing and of course redirect_uri validation.
>>
>>
>>
>> Best regards
>>
>>
>>
>> Sebastian
>>
>>
>>
>> * Von:* OAuth [mailto:oauth-bounces@ietf.org ] *=
Im
>> Auftrag von* Bill Burke
>> *Gesendet:* Freitag, 17. Februar 2017 00:14
>> *An:* oauth@ietf.org
>> *Betreff:* Re: [OAUTH-WG] Google's use of Implicit Grant Flow
>>
>>
>>
>> For our IDP [1], our javascript library uses the auth code flow, but
>> requires a public client, redirect_uri validation, and also does CORS
>> checks and processing.  We did not like Implicit Flow because
>>
>> 1) access tokens would be in the browser history
>>
>> 2) short lived access tokens (seconds or minutes) would require a browse=
r
>> redirect
>>
>> I'd be really curious to hear other's thoughts though.
>>
>> [1] http://keycloak.org
>> 
>>
>>
>>
>>
>>
>>
>>
>> On 2/16/17 5:44 PM, Jim Manico wrote:
>>
>> Hello Folks,
>>
>> I noticed that Google supports the OAuth 2 Implicit flow for third-party
>> JavaScript applications.
>>
>> https://developers.google.com/identity/protocols/OAuth2UserAgent
>> 
>>
>> Isn't this generally discouraged from a security POV? *Is there a better
>> OAuth 2 flow for third party SPA applications?*
>>
>> Aloha,
>>
>> --
>>
>> Jim Manico
>>
>> Manicode Security
>>
>> https://www.manicode.com 
>>
>>
>>
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>> OAuth@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/oauth 
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa=
uth 
>>
>>
>> --
>> Jim Manico
>> Manicode Securityhttps://www.manicode.com 
>>
>>
>> _______________________________________________
>> 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
>
>

--94eb2c0c0b823dd51f0548bdc256
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Can you describe the aspects that make a JS client library=
 "solid"? This is what I think would be useful to see written up =
in a document like the Native Apps one.

It's interes=
ting to me that so many of you have independently opted to use the auth cod=
e flow for Javascript apps. I think that's a sign that it's a bette=
r recommendation than the implicit flow for JS apps.

----
Aaron Parecki


On Fri, Feb 17, 2017 at 10:02 AM, Dominick B=
aier <dbaier@leastprivilege.com> wrote:
Given a solid=
 client library for JS, I think implicit flow is OK to use.=C2=A0
=

But I agree that there are many =E2=80=9Chome grown=E2=80=9D =
implementation out there that are not secure - and the necessary JS code to=
 write a good client is not necessarily the =E2=80=9Cpit of success=E2=80=
=9D.

You should give this lib a go (it=E2=80=99s als=
o a certified RP):

https://github.com/IdentityModel=
/oidc-client-js
 

Many people argue that handling th=
e protocol and crypto pieces in JS is problematic (and I agree if no proper=
 lib is used for that) - but at then end of the day the access token will e=
nd up in the browser - and a sloppy developer (e.g. not using CSP) will alw=
ays write bad code that might lead to leaking a token.
 

-------
Dominick Baier
=

 
On 17 February 2017 at 18:43:25, Adam Lewis (adam.lewis@motorolasolutions.<=
wbr>com) wrote:
 







+1000




We are currently going through internal turmoil over the usage
of implicit grant for ua-based apps.=C2=A0 The webapp case is well
understood and the WG has work in progress to define best practices
for native apps.=C2=A0 Having one for ua-based apps would be HUGELY
beneficial













On Fri, Feb 17, 2017 at 11:40 AM, Jim
Manico <jim@manicode.com> wrote:






Thank you to those answering my question on implicit for JS
clients.


The responses so far seem to represent what the security world
is saying=C2=A0 about the implicit grant - keep away from it other
than for a few OIDC use cases.


Does anyone think it would be valuable to author a brief RFC to
give clear OAuth 2 recommendations for JavaScript client
developers?


I mean - the OAuth 2 body of work just needs a few more RFC's,
right? :)


Aloha, Jim











O=
n 2/17/17 6:03
AM, Seb=
astian.Ebling@telekom.de wrote:







Same for Deutsche Telekom. Our javascript clients also use code
flow with CORS processing and of course redirect_uri
validation.


=C2=A0


Best regar=
ds


=C2=A0


Sebastian<=
/span>


=C2=A0







Von: 
OAuth [mailto:o=
auth-bounces@ietf.org] Im Auftrag
von Bill Burke

Gesendet: Freitag, 17. Februar 2017 00:14

An: oauth@iet=
f.org

Betreff: Re: [OAUTH-WG] Google's use of Implicit Grant
Flow






=C2=A0


For our IDP [1], our javascript library uses the auth code flow,
but requires a public client, redirect_uri validation, and also
does CORS checks and processing.=C2=A0 We did not like Implicit
Flow because


1) access tokens would be in the browser history


2) short lived access tokens (seconds or minutes) would require
a browser redirect


I'd be really curious to hear other's thoughts though.


[1] http://keycloak.org


=C2=A0


=C2=A0


=C2=A0




On 2/16/17 5:44 PM, Jim Manico wrote:






Hello Folks,


I noticed that Google supports the OAuth 2 Implicit flow for
third-party JavaScript applications.


https://developers.=
google.com/identity/protocols/OAuth2UserAgent


Isn't this generally discouraged from a security POV? Is
there a better OAuth 2 flow for third party SPA
applications?


Aloha,




-- 


Jim Manico


Manicode Security


https://www.manicode.com









_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/list=
info/oauth


=C2=A0












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





-- =20
Jim Manico
Manicode Security
https://www.manicode.com







_______________________________________________

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





--94eb2c0c0b823dd51f0548bdc256--


From nobody Fri Feb 17 10:06:27 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3168E129B19 for ; Fri, 17 Feb 2017 10:06:26 -0800 (PST)
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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc36LFCGtaM9 for ; Fri, 17 Feb 2017 10:06:23 -0800 (PST)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e: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 D342A129B17 for ; Fri, 17 Feb 2017 10:06:23 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id 189so15145007pfu.3 for ; Fri, 17 Feb 2017 10:06:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=b1j+Ef3OSbdizmjMLFpX/bnvS4Z6RR8GFGSIaOzvxX4=; b=VLxr56brHezU5+VZE0FBVn4AlLLikp9QBJsWVg8MUX6nBd5BPsO7c67oEJ6yCCtCOg OODWMQ1FNMlYaoKF/oP1rMW9GniqRQxyQafmDaLHw3N228LkpQ7S3crh87lSxjHQxl6q 6Ri4IVQwRKHVmccnC4YyiPoi1YFMYGyDM8VdE8rnMSsr3fLyCu235088Db/zxdX4iCcy EkojAxKEgBl6AAHH1iYbesIxJykLadBOT5uGEc49yyLiq9bwgu4YNtjsmga6dYlV9drL MOWa1ATXq9qGkKzOXl+1rAP33Rodpm9M+VFfsKuM+LYqVElzNW6tGhVIKSps7rPBnQjg sRSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=b1j+Ef3OSbdizmjMLFpX/bnvS4Z6RR8GFGSIaOzvxX4=; b=n/3n4vMU4y7BopPvk06doEl/JChbU59S1h/YvaB5vpuM5KtabxcrV7MSYQmw+CxMn2 sdKEs5BNKQK6gh7h/J5dMyJPU0s1r7zCUhIGCLfQ8i5QgyK9jgviLBsLcCl7YI1JAeez CABPuJSHmwktIswGokGgE2rnkXdLGqep/xd72ewDwz7waBafxiVon9UsJRyJ9rZcw7Yy gwCwJjpSVGOs9RaI/XMYnlst/ae55XE+hXyR/9eq0KinV430Z8QtxZU0VE6wU3xl0isr Zgjwc9cpggbPsaW2RNHPukglQXsyH4iJBqhtxho+qxECflgCFB2X9OIg7S4q+v+OLz2P D8VA==
X-Gm-Message-State: AMke39nX11ViYg4e7alYV71pzwOF+Ew4vFjrgLL0ofin8AP6waenviEEnvmNjJthK/yURzsa
X-Received: by 10.84.160.197 with SMTP id v5mr13023556plg.161.1487354783219; Fri, 17 Feb 2017 10:06:23 -0800 (PST)
Received: from heembo.local ([2605:e000:112b:c167:3519:b801:95b1:4955]) by smtp.googlemail.com with ESMTPSA id a24sm20887175pfh.33.2017.02.17.10.06.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 10:06:22 -0800 (PST)
To: Dominick Baier , Adam Lewis 
References: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com> <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com> <600a2fe3fbc147588baedb557e6e5938@HE105717.emea1.cds.t-internal.com> <9f795a60-5345-61b6-356a-cc871164ba8d@manicode.com>  
From: Jim Manico 
Message-ID: <1beba8d4-2979-03e1-44a3-da5ee2f00b93@manicode.com>
Date: Fri, 17 Feb 2017 08:06:20 -1000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C961F416ED28AF25DB1F5EBA"
Archived-At: 
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Google's use of Implicit Grant Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 18:06:26 -0000

This is a multi-part message in MIME format.
--------------C961F416ED28AF25DB1F5EBA
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

> Given a solid client library for JS, I think implicit flow is OK to use.

If you can, can you dig deeper here? What is it about this particular
library that makes its use of the OAuth 2 implicit flow secure? Signed
messages? Only supports registered clients? Something else?

Aloha, Jim


On 2/17/17 8:02 AM, Dominick Baier wrote:
> Given a solid client library for JS, I think implicit flow is OK to use. 
>
> But I agree that there are many “home grown†implementation out there
> that are not secure - and the necessary JS code to write a good client
> is not necessarily the “pit of successâ€.
>
> You should give this lib a go (it’s also a certified RP):
>
> https://github.com/IdentityModel/oidc-client-js
>
> Many people argue that handling the protocol and crypto pieces in JS
> is problematic (and I agree if no proper lib is used for that) - but
> at then end of the day the access token will end up in the browser -
> and a sloppy developer (e.g. not using CSP) will always write bad code
> that might lead to leaking a token.
>
> -------
> Dominick Baier
>
> On 17 February 2017 at 18:43:25, Adam Lewis
> (adam.lewis@motorolasolutions.com
> ) wrote:
>
>> +1000
>>
>> We are currently going through internal turmoil over the usage of
>> implicit grant for ua-based apps.  The webapp case is well understood
>> and the WG has work in progress to define best practices for native
>> apps.  Having one for ua-based apps would be HUGELY beneficial
>>
>>
>>
>> On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico > > wrote:
>>
>>     Thank you to those answering my question on implicit for JS clients.
>>
>>     The responses so far seem to represent what the security world is
>>     saying  about the implicit grant - keep away from it other than
>>     for a few OIDC use cases.
>>
>>     Does anyone think it would be valuable to author a brief RFC to
>>     give clear OAuth 2 recommendations for JavaScript client developers?
>>
>>     I mean - the OAuth 2 body of work just needs a few more RFC's,
>>     right? :)
>>
>>     Aloha, Jim
>>
>>
>>
>>     On 2/17/17 6:03 AM, Sebastian.Ebling@telekom.de
>>      wrote:
>>>
>>>     Same for Deutsche Telekom. Our javascript clients also use code
>>>     flow with CORS processing and of course redirect_uri validation.
>>>
>>>      
>>>
>>>     Best regards
>>>
>>>      
>>>
>>>     Sebastian
>>>
>>>      
>>>
>>>     *Von:* OAuth [mailto:oauth-bounces@ietf.org] *Im Auftrag von*
>>>     Bill Burke
>>>     *Gesendet:* Freitag, 17. Februar 2017 00:14
>>>     *An:* oauth@ietf.org 
>>>     *Betreff:* Re: [OAUTH-WG] Google's use of Implicit Grant Flow
>>>
>>>      
>>>
>>>     For our IDP [1], our javascript library uses the auth code flow,
>>>     but requires a public client, redirect_uri validation, and also
>>>     does CORS checks and processing.  We did not like Implicit Flow
>>>     because
>>>
>>>     1) access tokens would be in the browser history
>>>
>>>     2) short lived access tokens (seconds or minutes) would require
>>>     a browser redirect
>>>
>>>     I'd be really curious to hear other's thoughts though.
>>>
>>>     [1] http://keycloak.org
>>>     
>>>
>>>      
>>>
>>>      
>>>
>>>      
>>>
>>>     On 2/16/17 5:44 PM, Jim Manico wrote:
>>>
>>>         Hello Folks,
>>>
>>>         I noticed that Google supports the OAuth 2 Implicit flow for
>>>         third-party JavaScript applications.
>>>
>>>         https://developers.google.com/identity/protocols/OAuth2UserAgent
>>>         
>>>
>>>         Isn't this generally discouraged from a security POV? *Is
>>>         there a better OAuth 2 flow for third party SPA applications?*
>>>
>>>         Aloha,
>>>
>>>         -- 
>>>
>>>         Jim Manico
>>>
>>>         Manicode Security
>>>
>>>         https://www.manicode.com
>>>         
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>
>>>         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
>>>     
>>     --  
>>     Jim Manico
>>     Manicode Security
>>     https://www.manicode.com
>>     
>>
>>     _______________________________________________ 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 
-- 
Jim Manico
Manicode Security
https://www.manicode.com

--------------C961F416ED28AF25DB1F5EBA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
> Given a solid client library for JS, I think implicit flow
      is OK to use. 

    

    
If you can, can you dig deeper here? What is it about this
      particular library that makes its use of the OAuth 2 implicit flow
      secure? Signed messages? Only supports registered clients?
      Something else?

    
Aloha, Jim

    

    

    
On 2/17/17 8:02 AM, Dominick Baier
      wrote:

    

    

      
      
Given
        a solid client library for JS, I think implicit flow is OK to
        use. 

      


      

      
But
        I agree that there are many “home grown†implementation out
        there that are not secure - and the necessary JS code to write a
        good client is not necessarily the “pit of successâ€.

      


      

      
You
        should give this lib a go (it’s also a certified RP):

      


      

      
      


      

      Many people argue that handling the protocol and crypto pieces in
      JS is problematic (and I agree if no proper lib is used for that)
      - but at then end of the day the access token will end up in the
      browser - and a sloppy developer (e.g. not using CSP) will always
      write bad code that might lead to leaking a token.

      

        


        

        
-------

        
Dominick Baier

      

      

      
On 17 February 2017 at 18:43:25, Adam Lewis
        (adam.lewis@motorolasolutions.com)
        wrote:

      

          

            

              
              
+1000
                


                

                
We are currently going through internal turmoil
                  over the usage
                  of implicit grant for ua-based apps.  The webapp case
                  is well
                  understood and the WG has work in progress to define
                  best practices
                  for native apps.  Having one for ua-based apps would
                  be HUGELY
                  beneficial

                


                

                


                

              

              


                
On Fri, Feb 17, 2017 at 11:40
                  AM, Jim
                  Manico <jim@manicode.com>
                  wrote:

                  

                    

                      
Thank you to those answering my question on
                        implicit for JS
                        clients.

                      

                      
The responses so far seem to represent what the
                        security world
                        is saying  about the implicit grant - keep away
                        from it other
                        than for a few OIDC use cases.

                      

                      
Does anyone think it would be valuable to
                        author a brief RFC to
                        give clear OAuth 2 recommendations for
                        JavaScript client
                        developers?

                      
I mean - the OAuth 2 body of work just needs a
                        few more RFC's,
                        right? :)

                      
Aloha, Jim

                      

                      

                        

                          


                          

                          

                          
On
                            2/17/17 6:03
                            AM, Sebastian.Ebling@telekom.de
                            wrote:

                          

                          

                            

                              
Same
                                  for Deutsche Telekom. Our javascript clients
                                  also use code
                                  flow with CORS processing and of
                                  course redirect_uri
                                  validation.

                              
 

                              
Best regards

                              
 

                              
Sebastian

                              
 

                              

                                

                                  
Von:
                                    OAuth
                                      [mailto:oauth-bounces@ietf.org]
                                      Im Auftrag
                                        von Bill Burke

                                      Gesendet: Freitag, 17.
                                      Februar 2017 00:14

                                      An: oauth@ietf.org

                                      Betreff: Re: [OAUTH-WG]
                                      Google's use of Implicit Grant
                                      Flow

                                

                              

                              
 

                              
For our IDP [1], our javascript library
                                uses the auth code flow,
                                but requires a public client,
                                redirect_uri validation, and also
                                does CORS checks and processing.  We did
                                not like Implicit
                                Flow because

                              
1) access tokens would be in the
                                browser history

                              
2) short lived access tokens (seconds
                                or minutes) would require
                                a browser redirect

                              
I'd be really curious to hear other's
                                thoughts though.

                              
[1] http://keycloak.org

                              
 

                              
 

                              
 

                              

                                
On 2/16/17 5:44 PM,
                                  Jim Manico wrote:

                              

                              

                                
Hello Folks,

                                
I noticed that Google supports the
                                  OAuth 2 Implicit flow for
                                  third-party JavaScript applications.

                                
https://developers.google.com/identity/protocols/OAuth2UserAgent

                                
Isn't this generally discouraged from
                                  a security POV? Is
                                    there a better OAuth 2 flow for
                                    third party SPA
                                    applications?

                                
Aloha,

                                  

                                

                                
-- 

                                
Jim Manico

                                
Manicode Security

                                
https://www.manicode.com

                                


                                  

                                  

                                

                                
_______________________________________________


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





--  
Jim Manico
Manicode Security
https://www.manicode.com







_______________________________________________

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









-- 
Jim Manico
Manicode Security
https://www.manicode.com

--------------C961F416ED28AF25DB1F5EBA--


From nobody Fri Feb 17 10:07:39 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D11129B19 for ; Fri, 17 Feb 2017 10:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level: 
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kUymyHPR5rH for ; Fri, 17 Feb 2017 10:07:36 -0800 (PST)
Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::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 53DED129631 for ; Fri, 17 Feb 2017 10:07:36 -0800 (PST)
Received: by mail-pg0-x234.google.com with SMTP id v184so17339121pgv.3 for ; Fri, 17 Feb 2017 10:07:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=ZWOSfqL0UZzPGiXO8Bvc56M8UFuTCvQ/WSaXvA+wASw=; b=Ba6LbOGy7ok6pxmPBsScxByod+I2F+EZRevFPfJJmvmUTLdXTaZ8YIlTHCp1+xcMcn 4dH0UXG+JplGgJJm/N2yGU12a4fXFvdzgUXz42YdbYd1MoBuSe73zdtAu5ONjtvrlAh8 Z2UhtdLgJE7DtrJIyAueYrHsJ+2wh4SS21suJiZghi/oRHQS0p2O3Ly7KXI2cu6pDUGt HUpYxNccqqqCQYCxyegxVQnGrGsWhDGdzmHu2jJM7Hhz4PMK70KDy6/4FPSAvRd5i1KE 0YpKCTEfY6iscuZkTOYsyL1mP1YmM0z/REf76JD1pj8Jw4NvPhJaXE6Ox1qNJ1XjYcwF vFwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=ZWOSfqL0UZzPGiXO8Bvc56M8UFuTCvQ/WSaXvA+wASw=; b=C9GjJt7WF4He7SHM2GVoyTJ+yVhNubRbL2Tio92g71eGCEgH/3xBID3FB1CGNCKpYm IofJQUnr8X1fP/VRxEAqOf8jfq2afsJPOJ1ebYMntDQxHdoH7ASgoP5UjbD1rOV3HjJy uel9caEzxXsRTlJrkeMWKdWyQpV8ayqJ4RMEduKCHP+aq0JTJOqzAQTWSF48HVaf7IdB nvoWV6myeT1k5jWEfQ72EWh6xSqMKGFQWsConnCZ59oZd/122z8CJTKl57MORM/kjdnk /DOgnEg8lm4I0CNp/8ZD/vh725T1d0RfbktTKv58c7ozhh8M4sV7gxXqvVuZxYEXe0IB bKWQ==
X-Gm-Message-State: AMke39kamKL75vZkJwjKPUzCEJl7PJICWytPshH7xBTXn1euDl4fb9rvK8Az5GiaYZUwfUYv
X-Received: by 10.84.232.134 with SMTP id i6mr13005035plk.101.1487354855800; Fri, 17 Feb 2017 10:07:35 -0800 (PST)
Received: from heembo.local ([2605:e000:112b:c167:3519:b801:95b1:4955]) by smtp.googlemail.com with ESMTPSA id s3sm20996547pgn.55.2017.02.17.10.07.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Feb 2017 10:07:35 -0800 (PST)
To: Aaron Parecki , Dominick Baier 
References: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com> <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com> <600a2fe3fbc147588baedb557e6e5938@HE105717.emea1.cds.t-internal.com> <9f795a60-5345-61b6-356a-cc871164ba8d@manicode.com>   
From: Jim Manico 
Message-ID: <94d7c3a8-af15-a454-4c05-341bbe92cd3d@manicode.com>
Date: Fri, 17 Feb 2017 08:07:33 -1000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------D799B2DA72C85A021072A02B"
Archived-At: 
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Google's use of Implicit Grant Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 18:07:38 -0000

This is a multi-part message in MIME format.
--------------D799B2DA72C85A021072A02B
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

+1 I'm with you Aaron. I am not as well versed as other members of this
standard body in OAuth but I would be happy to help build this document
if folks with more experience would help.

- Jim


On 2/17/17 8:05 AM, Aaron Parecki wrote:
> Can you describe the aspects that make a JS client library "solid"?
> This is what I think would be useful to see written up in a document
> like the Native Apps one.
>
> It's interesting to me that so many of you have independently opted to
> use the auth code flow for Javascript apps. I think that's a sign that
> it's a better recommendation than the implicit flow for JS apps.
>
> ----
> Aaron Parecki
> aaronparecki.com 
> @aaronpk 
>
>
> On Fri, Feb 17, 2017 at 10:02 AM, Dominick Baier
> > wrote:
>
>     Given a solid client library for JS, I think implicit flow is OK
>     to use. 
>
>     But I agree that there are many “home grown†implementation out
>     there that are not secure - and the necessary JS code to write a
>     good client is not necessarily the “pit of successâ€.
>
>     You should give this lib a go (it’s also a certified RP):
>
>     https://github.com/IdentityModel/oidc-client-js
>     
>
>     Many people argue that handling the protocol and crypto pieces in
>     JS is problematic (and I agree if no proper lib is used for that)
>     - but at then end of the day the access token will end up in the
>     browser - and a sloppy developer (e.g. not using CSP) will always
>     write bad code that might lead to leaking a token.
>
>     -------
>     Dominick Baier
>
>     On 17 February 2017 at 18:43:25, Adam Lewis
>     (adam.lewis@motorolasolutions.com
>     ) wrote:
>
>>     +1000
>>
>>     We are currently going through internal turmoil over the usage of
>>     implicit grant for ua-based apps.  The webapp case is well
>>     understood and the WG has work in progress to define best
>>     practices for native apps.  Having one for ua-based apps would be
>>     HUGELY beneficial
>>
>>
>>
>>     On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico >     > wrote:
>>
>>         Thank you to those answering my question on implicit for JS
>>         clients.
>>
>>         The responses so far seem to represent what the security
>>         world is saying  about the implicit grant - keep away from it
>>         other than for a few OIDC use cases.
>>
>>         Does anyone think it would be valuable to author a brief RFC
>>         to give clear OAuth 2 recommendations for JavaScript client
>>         developers?
>>
>>         I mean - the OAuth 2 body of work just needs a few more
>>         RFC's, right? :)
>>
>>         Aloha, Jim
>>
>>
>>
>>         On 2/17/17 6:03 AM, Sebastian.Ebling@telekom.de
>>          wrote:
>>>
>>>         Same for Deutsche Telekom. Our javascript clients also use
>>>         code flow with CORS processing and of course redirect_uri
>>>         validation.
>>>
>>>          
>>>
>>>         Best regards
>>>
>>>          
>>>
>>>         Sebastian
>>>
>>>          
>>>
>>>         *Von:* OAuth [mailto:oauth-bounces@ietf.org] *Im Auftrag
>>>         von* Bill Burke
>>>         *Gesendet:* Freitag, 17. Februar 2017 00:14
>>>         *An:* oauth@ietf.org 
>>>         *Betreff:* Re: [OAUTH-WG] Google's use of Implicit Grant Flow
>>>
>>>          
>>>
>>>         For our IDP [1], our javascript library uses the auth code
>>>         flow, but requires a public client, redirect_uri validation,
>>>         and also does CORS checks and processing.  We did not like
>>>         Implicit Flow because
>>>
>>>         1) access tokens would be in the browser history
>>>
>>>         2) short lived access tokens (seconds or minutes) would
>>>         require a browser redirect
>>>
>>>         I'd be really curious to hear other's thoughts though.
>>>
>>>         [1] http://keycloak.org
>>>         
>>>
>>>          
>>>
>>>          
>>>
>>>          
>>>
>>>         On 2/16/17 5:44 PM, Jim Manico wrote:
>>>
>>>             Hello Folks,
>>>
>>>             I noticed that Google supports the OAuth 2 Implicit flow
>>>             for third-party JavaScript applications.
>>>
>>>             https://developers.google.com/identity/protocols/OAuth2UserAgent
>>>             
>>>
>>>             Isn't this generally discouraged from a security POV?
>>>             *Is there a better OAuth 2 flow for third party SPA
>>>             applications?*
>>>
>>>             Aloha,
>>>
>>>             -- 
>>>
>>>             Jim Manico
>>>
>>>             Manicode Security
>>>
>>>             https://www.manicode.com
>>>             
>>>
>>>
>>>
>>>
>>>             _______________________________________________
>>>
>>>             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
>>>         
>>         --  
>>         Jim Manico
>>         Manicode Security
>>         https://www.manicode.com
>>         
>>
>>         _______________________________________________ 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
>      
>
-- 
Jim Manico
Manicode Security
https://www.manicode.com

--------------D799B2DA72C85A021072A02B
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
+1 I'm with you Aaron. I am not as well versed as other members
      of this standard body in OAuth but I would be happy to help build
      this document if folks with more experience would help.

    
- Jim

    

    

    
On 2/17/17 8:05 AM, Aaron Parecki
      wrote:

    

    

      
Can you describe the aspects that make a JS client
        library "solid"? This is what I think would be useful to see
        written up in a document like the Native Apps one.
        


        

        
It's interesting to me that so many of you have
          independently opted to use the auth code flow for Javascript
          apps. I think that's a sign that it's a better recommendation
          than the implicit flow for JS apps.

      

      


        

          

            
----

            
Aaron Parecki

            
            
            


            

          

        

        

        
On Fri, Feb 17, 2017 at 10:02 AM,
          Dominick Baier <dbaier@leastprivilege.com>
          wrote:

          

            

              
Given
                a solid client library for JS, I think implicit flow is
                OK to use. 

              


              

              
But
                I agree that there are many “home grown†implementation
                out there that are not secure - and the necessary JS
                code to write a good client is not necessarily the “pit
                of successâ€.

              


              

              
You
                should give this lib a go (it’s also a certified RP):

              


              

              
https://github.com/IdentityModel/oidc-client-js

              


              

              Many people argue that handling the protocol and crypto
              pieces in JS is problematic (and I agree if no proper lib
              is used for that) - but at then end of the day the access
              token will end up in the browser - and a sloppy developer
              (e.g. not using CSP) will always write bad code that might
              lead to leaking a token.

              

                


                

                
-------

                
Dominick Baier

              

              

                
 

                  
On 17
                    February 2017 at 18:43:25, Adam Lewis (adam.lewis@motorolasolutions.com)
                    wrote:

                  

                      

                        

                          
+1000
                            


                            

                            
We are currently going through internal
                              turmoil over the usage
                              of implicit grant for ua-based apps.  The
                              webapp case is well
                              understood and the WG has work in progress
                              to define best practices
                              for native apps.  Having one for ua-based
                              apps would be HUGELY
                              beneficial

                            


                            

                            


                            

                          

                          


                            
On Fri, Feb 17,
                              2017 at 11:40 AM, Jim
                              Manico <jim@manicode.com>
                              wrote:

                              

                                

                                  
Thank you to those answering my
                                    question on implicit for JS
                                    clients.

                                  

                                  
The responses so far seem to
                                    represent what the security world
                                    is saying  about the implicit grant
                                    - keep away from it other
                                    than for a few OIDC use cases.

                                  

                                  
Does anyone think it would be
                                    valuable to author a brief RFC to
                                    give clear OAuth 2 recommendations
                                    for JavaScript client
                                    developers?

                                  
I mean - the OAuth 2 body of work
                                    just needs a few more RFC's,
                                    right? :)

                                  
Aloha, Jim

                                  

                                  

                                    

                                      


                                      

                                      

                                      
On
                                        2/17/17 6:03
                                        AM, Sebastian.Ebling@telekom.de
                                        wrote:

                                      

                                      

                                        

                                          
Same
                                              for Deutsche Telekom.
                                            Our
                                              javascript clients also
                                              use code
                                              flow with CORS processing
                                              and of course redirect_uri
                                              validation.

                                          
 

                                          
Best regards

                                          
 

                                          
Sebastian

                                          
 

                                          

                                            

                                              

                                                    Von: 
                                                  OAuth [mailto:oauth-bounces@ietf.org]
                                                  Im Auftrag
                                                    von Bill Burke

                                                  Gesendet:
                                                  Freitag, 17. Februar
                                                  2017 00:14

                                                  An: oauth@ietf.org

                                                  Betreff: Re:
                                                  [OAUTH-WG] Google's
                                                  use of Implicit Grant
                                                  Flow

                                            

                                          

                                          
 

                                          
For our IDP [1], our
                                            javascript library uses the
                                            auth code flow,
                                            but requires a public
                                            client, redirect_uri
                                            validation, and also
                                            does CORS checks and
                                            processing.  We did not like
                                            Implicit
                                            Flow because

                                          
1) access tokens would be
                                            in the browser history

                                          
2) short lived access
                                            tokens (seconds or minutes)
                                            would require
                                            a browser redirect

                                          
I'd be really curious to
                                            hear other's thoughts
                                            though.

                                          
[1] http://keycloak.org

                                          
 

                                          
 

                                          
 

                                          

                                            
On
                                              2/16/17 5:44 PM, Jim
                                              Manico wrote:

                                          

                                          

                                            
Hello Folks,

                                            
I noticed that Google
                                              supports the OAuth 2
                                              Implicit flow for
                                              third-party JavaScript
                                              applications.

                                            
https://developers.google.com/identity/protocols/OAuth2UserAgent

                                            
Isn't this generally
                                              discouraged from a
                                              security POV? Is
                                                there a better OAuth 2
                                                flow for third party SPA
                                                applications?

                                            
Aloha,

                                              

                                            

                                            
-- 

                                            
Jim Manico

                                            
Manicode Security

                                            
https://www.manicode.com

                                            


                                              

                                              

                                            

                                            
_______________________________________________


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





--  
Jim Manico
Manicode Security
https://www.manicode.com







_______________________________________________

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












-- 
Jim Manico
Manicode Security
https://www.manicode.com

--------------D799B2DA72C85A021072A02B--


From nobody Fri Feb 17 10:25:18 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F79129B10 for ; Fri, 17 Feb 2017 10:25:16 -0800 (PST)
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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=leastprivilege-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ReUn27RBVSu for ; Fri, 17 Feb 2017 10:25:14 -0800 (PST)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425E0129686 for ; Fri, 17 Feb 2017 10:25:14 -0800 (PST)
Received: by mail-yw0-x22c.google.com with SMTP id l19so26970053ywc.2 for ; Fri, 17 Feb 2017 10:25:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=LRFMer3V3mX4nM0N2Isuw27pnix+l8L3EESDCLBgGt4=; b=eSjb2CcsLmypkkyPlX8tZHxC8YvC8Vu2PwFePyAMdmvdEQPU4QLekiubFKgSiwpVGT ZKkqoRJu+6eefRN2Z5NJbWexKBK0JCMBVqBxj42z+TlmUlNVuLoDL8ZFO6eeLjJ2d1l/ Gd1VuYcFcjS5NWMj8JBEmFodzLvb4STxC4ugyrxrjjcJ7I9uSshnZEjlIe/Nf3p6TWfg /TjwuPksQQR/Wx+oSbcl3k4UgkKyKGrCRyqcRu505Br6PpVSuFQkC8lQiGBkzso63Ql5 SrA3r2EvUZ7G+SiCNF6AGUBNMSouXmlKqUYj1M4bF4YoCnhN71Qr8vpmn4XL1fNFRUao K89w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=LRFMer3V3mX4nM0N2Isuw27pnix+l8L3EESDCLBgGt4=; b=hMzOL8vNcIeQIvxTkgTAPbTXoD7sn3ARxEOYTkEn386r/6BChGqigMdPCC46qD0N8p x5PBNsdmBW2ZJ4at5XnZYzsCa+iM8v2smVZ83/e+vu4SmUUgpQAHLLcMteXijPjSgxQc 58z+Kq7EUcnhcroY1PPnhXpbJIFKbd2DL8dHpQMwNLHY+q89hKghACQYUqeWwkAasjSH XmSRPWBbTeIv990eHw7VsaySro/19g461YA/7yDX+I5J34HK3+jSp2tawQpNfeKqFFre 4iddtz4qbtnsQNsbjfIW+GqbQQoL+wn8hjVPwMsBWFB7VDQGUA/ZtQcsOZloAGVu0Qq1 gy0g==
X-Gm-Message-State: AMke39mefBNLiKPIVaCWA/bfENpTE3ng9pwgiaiKR2b0TA2JozUw27uclfaTOs07+U9nDTV0ybHcH/zV9lspXg==
X-Received: by 10.129.117.214 with SMTP id q205mr6748311ywc.212.1487355911975;  Fri, 17 Feb 2017 10:25:11 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 17 Feb 2017 13:25:11 -0500
From: Dominick Baier 
In-Reply-To: <1beba8d4-2979-03e1-44a3-da5ee2f00b93@manicode.com>
References: <1e63222f-1d3b-59cc-a7c3-f9f3aa14e9df@manicode.com> <5d69eb72-b99a-1605-b58b-b7f33bb5db60@redhat.com> <600a2fe3fbc147588baedb557e6e5938@HE105717.emea1.cds.t-internal.com> <9f795a60-5345-61b6-356a-cc871164ba8d@manicode.com>   <1beba8d4-2979-03e1-44a3-da5ee2f00b93@manicode.com>
X-Mailer: Airmail (397)
MIME-Version: 1.0
Date: Fri, 17 Feb 2017 13:25:11 -0500
Message-ID: 
To: Adam Lewis , Jim Manico 
Content-Type: multipart/alternative; boundary=001a1147f990c9d9380548be08d6
Archived-At: 
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Google's use of Implicit Grant Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 18:25:17 -0000

--001a1147f990c9d9380548be08d6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Well - first of all that it uses all the recommend validation techniques

- state validation + protection
- nonce validation
- at_hash validation
- identity token validation
- discovery

+ solid and tested JS code

I don=E2=80=99t see extra value for a JS client in things like =E2=80=9Csig=
ned requests=E2=80=9D -
as I said before - at the end of the day the access token will end up in
the browser. Regardless how secure you made the authentication request in
the first place.


-------
Dominick Baier

On 17 February 2017 at 19:06:23, Jim Manico (jim@manicode.com) wrote:

> Given a solid client library for JS, I think implicit flow is OK to use.

If you can, can you dig deeper here? What is it about this particular
library that makes its use of the OAuth 2 implicit flow secure? Signed
messages? Only supports registered clients? Something else?

Aloha, Jim

On 2/17/17 8:02 AM, Dominick Baier wrote:

Given a solid client library for JS, I think implicit flow is OK to use.

But I agree that there are many =E2=80=9Chome grown=E2=80=9D implementation=
 out there that
are not secure - and the necessary JS code to write a good client is not
necessarily the =E2=80=9Cpit of success=E2=80=9D.

You should give this lib a go (it=E2=80=99s also a certified RP):

https://github.com/IdentityModel/oidc-client-js

Many people argue that handling the protocol and crypto pieces in JS is
problematic (and I agree if no proper lib is used for that) - but at then
end of the day the access token will end up in the browser - and a sloppy
developer (e.g. not using CSP) will always write bad code that might lead
to leaking a token.

-------
Dominick Baier

On 17 February 2017 at 18:43:25, Adam Lewis (
adam.lewis@motorolasolutions.com) wrote:

+1000

We are currently going through internal turmoil over the usage of implicit
grant for ua-based apps.  The webapp case is well understood and the WG has
work in progress to define best practices for native apps.  Having one for
ua-based apps would be HUGELY beneficial



On Fri, Feb 17, 2017 at 11:40 AM, Jim Manico  wrote:

> Thank you to those answering my question on implicit for JS clients.
>
> The responses so far seem to represent what the security world is saying
> about the implicit grant - keep away from it other than for a few OIDC us=
e
> cases.
>
> Does anyone think it would be valuable to author a brief RFC to give clea=
r
> OAuth 2 recommendations for JavaScript client developers?
>
> I mean - the OAuth 2 body of work just needs a few more RFC's, right? :)
>
> Aloha, Jim
>
>
>
> On 2/17/17 6:03 AM, Sebastian.Ebling@telekom.de wrote:
>
> Same for Deutsche Telekom. Our javascript clients also use code flow with
> CORS processing and of course redirect_uri validation.
>
>
>
> Best regards
>
>
>
> Sebastian
>
>
>
> * Von:* OAuth [mailto:oauth-bounces@ietf.org ] *I=
m
> Auftrag von* Bill Burke
> *Gesendet:* Freitag, 17. Februar 2017 00:14
> *An:* oauth@ietf.org
> *Betreff:* Re: [OAUTH-WG] Google's use of Implicit Grant Flow
>
>
>
> For our IDP [1], our javascript library uses the auth code flow, but
> requires a public client, redirect_uri validation, and also does CORS
> checks and processing.  We did not like Implicit Flow because
>
> 1) access tokens would be in the browser history
>
> 2) short lived access tokens (seconds or minutes) would require a browser
> redirect
>
> I'd be really curious to hear other's thoughts though.
>
> [1] http://keycloak.org
> 
>
>
>
>
>
>
>
> On 2/16/17 5:44 PM, Jim Manico wrote:
>
> Hello Folks,
>
> I noticed that Google supports the OAuth 2 Implicit flow for third-party
> JavaScript applications.
>
> https://developers.google.com/identity/protocols/OAuth2UserAgent
> 
>
> Isn't this generally discouraged from a security POV? *Is there a better
> OAuth 2 flow for third party SPA applications?*
>
> Aloha,
>
> --
>
> Jim Manico
>
> Manicode Security
>
> https://www.manicode.com 
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth 
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th 
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com 
>
> _______________________________________________ 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

--
Jim Manico
Manicode Securityhttps://www.manicode.com

--001a1147f990c9d9380548be08d6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=

Well - first of all that it uses all the recommen=
d validation techniques

- state validation + protection
- nonce validation
- at_hash validation
- identity token validation
- discovery

+ solid and tested JS code
=


I don=E2=80=99t see extra=
 value for a JS client in things like =E2=80=9Csigned requests=E2=80=9D - a=
s I said before - at the end of the day the access token will end up in the=
 browser. Regardless how secure you made the authentication request in the =
first place.
 
 

-------
Dominick Baier
 
On 17 February 2017 at 19:06:23, Jim Manico =
(jim@manicode.com) wrote:
 








> Given a solid client library for JS, I think implicit flow
is OK to use.


If you can, can you dig deeper here? What is it about this
particular library that makes its use of the OAuth 2 implicit flow
secure? Signed messages? Only supports registered clients?
Something else?


Aloha, Jim




On 2/17/17 8:02 AM, Dominick Baier
wrote:






Given a solid client library for JS, I think implicit flow is OK to
use.=C2=A0







But I agree that there are many =E2=80=9Chome grown=E2=80=9D implementation=
 out
there that are not secure - and the necessary JS code to write a
good client is not necessarily the =E2=80=9Cpit of success=E2=80=9D.







You should give this lib a go (it=E2=80=99s also a certified RP):









Many people argue that handling the protocol and crypto pieces in
JS is problematic (and I agree if no proper lib is used for that) -
but at then end of the day the access token will end up in the
browser - and a sloppy developer (e.g. not using CSP) will always
write bad code that might lead to leaking a token.







-------


Dominick Baier






On 17 February 2017 at 18:43:25, Adam Lewis
(adam.lewis@motorolasol=
utions.com)
wrote:








+1000




We are currently going through internal turmoil over the
usage of implicit grant for ua-based apps.=C2=A0 The webapp case is
well understood and the WG has work in progress to define best
practices for native apps.=C2=A0 Having one for ua-based apps would
be HUGELY beneficial













On Fri, Feb 17, 2017 at 11:40 AM,
Jim Manico <jim@manicode.com> wrote:






Thank you to those answering my question on implicit for JS
clients.


The responses so far seem to represent what the security world
is saying=C2=A0 about the implicit grant - keep away from it other
than for a few OIDC use cases.


Does anyone think it would be valuable to author a brief RFC to
give clear OAuth 2 recommendations for JavaScript client
developers?


I mean - the OAuth 2 body of work just needs a few more RFC's,
right? :)


Aloha, Jim











On 2/17/17 6:03
AM, Sebastian.Ebling@telekom.=
de wrote:







Same for Deutsche Telekom. Our javascript clients also use code
flow with CORS processing and of course redirect_uri
validation.


=C2=A0


Best regar=
ds


=C2=A0


Sebastian<=
/span>


=C2=A0



=C2=A0


For our IDP [1], our javascript library uses the auth code flow,
but requires a public client, redirect_uri validation, and also
does CORS checks and processing.=C2=A0 We did not like Implicit
Flow because


1) access tokens would be in the browser history


2) short lived access tokens (seconds or minutes) would require
a browser redirect


I'd be really curious to hear other's thoughts though.


[1] http://keycloak.org


=C2=A0


=C2=A0


=C2=A0




On 2/16/17 5:44 PM, Jim Manico wrote:






Hello Folks,


I noticed that Google supports the OAuth 2 Implicit flow for
third-party JavaScript applications.


https://developers.=
google.com/identity/protocols/OAuth2UserAgent


Isn't this generally discouraged from a security POV? Is
there a better OAuth 2 flow for third party SPA
applications?


Aloha,




-- 


Jim Manico


Manicode Security


https://www.manicode.com









_______________________________________________


OAuth mailing list


OAuth@ietf.org=



https://www.ietf.org/mailman/list=
info/oauth


=C2=A0








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



--  =20
Jim Manico
Manicode Security
https://w=
ww.manicode.com





_______________________________________________ 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/oau=
th








-- =20
Jim Manico
Manicode Security
https:=
//www.manicode.com






--001a1147f990c9d9380548be08d6--


From nobody Fri Feb 17 12:51:28 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8FC129A7A; Fri, 17 Feb 2017 12:51:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.617
X-Spam-Level: 
X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOxYF4sjuPCO; Fri, 17 Feb 2017 12:51:20 -0800 (PST)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 6E4E112954A; Fri, 17 Feb 2017 12:51:19 -0800 (PST)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id D4A4478032A; Fri, 17 Feb 2017 21:51:14 +0100 (CET)
To: Nat Sakimura , John Bradley 
References: <148581788158.29828.4591033587037530374.idtracker@ietfa.amsl.com> <3a6b8cee-ff29-323e-9042-5df6e71a8d81@free.fr>  <81f50f3f-2f04-c74a-d47a-dad8cd9f715a@free.fr> 
From: Denis 
Message-ID: 
Date: Fri, 17 Feb 2017 21:51:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------618BA1C5DDA1E51BA8BB3017"
Archived-At: 
Cc: oauth , draft-ietf-oauth-jwsreq@ietf.org
Subject: Re: [OAUTH-WG] Last Call:  (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Feb 2017 20:51:26 -0000

This is a multi-part message in MIME format.
--------------618BA1C5DDA1E51BA8BB3017
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Nat,

Thank you for the forwarding of the detailed responses made by John.
Instead of replying between the lines, I have grouped my concerns under 
7 items that are detailed below.

======================================================================

ITEM 1

======================================================================

RFC 6749 states in section 10.2 (from the security considerations 
section on page 54):

The authorization server SHOULD NOT process repeated authorization 
requests automatically
(without active resource owner interaction) without authenticating the 
client or relying on other measures
to ensure that the repeated request comes from the original client and 
not an impersonator.

With such a vague guidance that are dozens of possibilities, none of 
them is being defined.

How would two implementations be able to interoperate ? The answer is 
simple: they can't.

Nevertheless, replay protection of a Token Request should be addressed 
in the current draft and presently it isn't.
In order to address this concern, I make a proposal.

An Authorization Server should be able to "easily" check (i.e. without 
losing to much computing time in order to decrease
the efficiency of DoS attacks) whether a Token Request is a replay or 
not from a previous Token Request.

ISO/IEC 10181-2:1996 (Information technology -- Open Systems 
Interconnection -- Security frameworks for open systems:
Authentication framework) published more than 20 years ago defines two 
methods: the use of challenges or the use of unique numbers.
Unique numbers are also called "nonces" (as a contraction of "number 
once") but their meaning is fully different from the meaning made by
the OpenID Connect Core specification, since a unique number as defined 
in that specification is in fact a "challenge" as defined by ISO/IEC 
10181-2.


Hereafter is the definition of a nonce as defined in the OpenID Connect 
Core specification:

nonce

String value used to associate a Client session with an ID Token, and to 
mitigate replay attacks. The value is passed through unmodified
from the Authentication Request to the ID Token. If present in the ID 
Token, Clients MUST verify that the nonceClaim Value is equal to
µthe value of the nonceparameter sent in the Authentication Request. If 
present in the Authentication Request, Authorization Servers MUST
include a nonceClaim in the ID Token with the Claim Value being the 
nonce value sent in the Authentication Request. Authorization Servers
SHOULD perform no other processing on noncevalues used. The noncevalue 
is a case sensitive string.


A unique number (according to ISO/IEC 10181-2) is generated by a client 
and is used by a server to check the freshness of a request
without the need for the server to remember it more than a couple or a 
dozen of minutes. It is composed of a UTC time and a random number.
A unique number is generated by the client and checked by the 
Authorization Server.

Similarly, in order to allow a Client to verify that the Access Token 
corresponds to the content of the Authorization Request,
some data SHOULD be included in the Access Token.

The OpenID Connect Core specification has defined a "nonce" that allows 
to perform the second check, but not to perform the first one.

In order to avoid the Authorization Server to remember unique numbers 
(as defined in ISO/IEC 10181-2) for ever, each Authorization Request needs
to contain a UTC time, so that unique numbers that are out of a time 
window (of, let us say, a couple or a dozen of minutes) can be removed
from the memory the Authorization Server.

Fortunately, RFC 7519, Section 4.1.6 has defined "iat" which means 
"Issued At".

This means that the Authorization Request as defined in the draft 
specification SHALL contain a unique number that consists of
both a "iat" parameter and a random number.

Let us call that second parameter "rdn" for "random number" and let us 
register it at IANA it /within this future RFC/ as a being an int32,
which is quite sufficient for the intended purpose.

rdn

Integer value used by a Client in an Authentication Request for two 
purposes. Firstly, when associated with a "iat" parameter,
to allow an Authorization Server to detect the replay of an 
Authentication Request and secondly to allow a Client to check
the freshness of an Access Token. In order to detect the replay of an 
Authentication Request, the Authorization Server MUST
be able to (a) use a local clock loosely synchronized with the UTC, and 
(b) construct a table where the "iat" parameter and
the "rdn" parameter from each well-formed and accepted Authentication 
Request are memorized. Only the "iat" parameters
and the "rdn" parameters received during a short time window (e.g. a 
couple or dozen of minutes) need to be memorized.

After checking that the Authentication Request is well formed, its 
processing SHOULD continue by checking that the "iat" parameter.
If the "iat" parameters is outside the time window, the Authentication 
Request SHALL be discarded by the Authorization Server.
If the "iat" parameters is inside the time window, the Authorization 
Server SHALL check if the "iat" parameter associated
with that "rdn" parameter are not already memorized in the table. If it 
is the case, the Authentication Request SHALL be discarded
by the Authorization Server. Otherwise, the Authentication Request is 
not a replay of a previous Authentication Request and
the processing of the Authentication Request SHOULD continue.

The value of the rdn parameter is passed through unmodified from the 
Authentication Request to the Authorization Server.
It MAY be included in the Access Token by the Authorization Server. If 
present in the Access Token, Clients MUST verify
that the rdn Claim Value is equal to the value of the rdn parameter sent 
in the Authentication Request and if it is not the case,
the Access Token SHALL be discarded.

Note that this allows to optimize the number of parameters without the 
need to use the nonce parameter (as defined in the OpenID Connect Core 
specification)
which is not defined in any RFC for the moment.

The end result of this argumentation is that the Authorization Request - 
as defined in this draft specification -
SHALL contain both an "iat" parameter and a "rdn" parameter. Please take 
a look at the next item before expressing a position on this item.

======================================================================

ITEM 2

======================================================================

Nat: The implementer of this document needs to consult RFC6749 closely 
anyway as all the verification requirements still holds,
so as an editor, I would rather keep it as it is. It is not "reader 
friendly" but cannot go wrong with the approach to just referencing RFC6749.

John: There are 4 flows in RFC6749. In each flow, there is a sub-section 
dedicated to the Authorization request.
In them, the parameters used in the authorization request are very 
clearly indicated. (...) Thus, it would be misleading just to say
the parameters defined in 4.1.1, 4.2.1, etc. As an editor, I feel better 
with the current language because it is at least not wrong nor misleading.

I proposed:

   Object *MUST contain a client_id parameter* and SHOULD contain a
    "iss" (issuer) *parameter* and an "aud" (audience) *parameter*, with
    their semantics being the same as defined in the JWT RFC7519]
    specification.

John:  I am kind of ok with the proposed text but if we do you want to 
single out `client_id`, perhaps a reason should be added.
There are other REQUIRED parameters in the Authorization Request defined 
in RFC6749, you know.

The mandatory parameters to be included in the request should be 
identified. They are composed of :

(a)the common denominator of the REQUIRED parameters defined in 4.1.1, 
4.2.1, etc,

(b)the parameters that are necessary to address the detection of the 
replay of previous well-formed requests, and

(c)the parameters that are necessary to address the detection of the 
replay of a previous well-formed token.

The common denominator of the REQUIRED parameters defined in 4.1.1, 
4.2.1, etc, is the client_id parameter (indicated as "REQUIRED").

The parameters that are necessary to address the detection of the two 
cases of replay are the "iat" and the "rdn" parameters.

As a reader, I feel better to know which parameters are REQUIRED, 
leaving other details in RFC 6749.

As a conclusion, the draft should indicate that the following parameters 
are always REQUIRED: client_id, iat and rdn.

Hence my proposal:

*Object MUST contain a "client_id" parameter, i.e. **a string 
representing the registration information
provided by the end-user that is unique to the authorization server,**an 
"iat" parameter and
a "rdn" parameter and SHOULD contain a "iss" (issuer) parameter and an 
"aud" (audience) parameter,
with their semantics being the same as defined in the JWT [RFC7519] 
specification.*

======================================================================

ITEM 3

======================================================================

Nat: ABC attack is out of scope for OAuth. It is not a new attack. The 
resource owner handing a bearer token
to another party willfully is not a threat in the bearer token model.

Nat: ABC attack is out of scope of RFC 6749 and RFC6750. They can be 
dealt with in POP document but not this one.

Denis: RFC 6749 (The OAuth 2.0 Authorization Framework) has been 
published in October 2012. RFC 6819 (OAuth 2.0 Threat Model and Security 
Considerations)
has been published in January 2013, hence after RFC 6749, so RFC 6749 
could not reference RFC 6819. /The carriage had been placed before the 
horse/.

RFC 6819 implicitly talks about the ABC attack in section 5.1.6:

5.1.6.Access Tokens

The following measures should be used to protect access tokens:

(...).

oEnsure that client applications do not share tokens with 3rd parties.

You said:"They can be dealt with in POP document".

Unfortunately, at the present time, this is not the case.

The key point is that none of the documents issued by the OAuth WG 
(neither by the Tokbind WG) indicates how to
"Ensure that client applications do not share tokens with 3rd parties".

The charter of the Tokbind WG (unbearable) states (see: 
https://datatracker.ietf.org/wg/tokbind/charter) :

"It is a goal of this working group to enable defense against attacks 
that involve unauthorized replay of security tokens.
Other issues associated with the use of security tokens are out of scope".

However, draft-ietf-tokbind-protocol-13 (The Token Binding Protocol 
Version 1.0) /issued yesterday/ explicitly states:

The Token Binding protocol does not prevent cooperating clients from

sharing a bound token. A client could intentionally export a bound

token with the corresponding Token Binding private key, or perform

signatures using this key on behalf of another client.

So neither the OAuth WG nor the TokBind WG have, at this time, a draft 
that is potentially able to counter the ABC attack.

So saying that the "ABC attack is out of scope for OAuth" is not the 
right wording.
Saying that the "ABC attack has not been taken into consideration for 
OAuth 2.0" is *a fact*.
That *fact *should not be hidden in the current draft.

Since it is unlikely that RFC 6819 will be soon replaced by another RFC, 
it is necessary to mention that threat in the security considerations 
section.
This does not mean that this threat shall be solved in the current 
draft, but readers should be aware that the ABC attack is not countered 
using this draft.

A text along the following one should be added into the security 
consideration section:

In case of a cooperation between clients, the format of the JWT Secured 
Authorization Request
described in this document does not prevent a client from asking a token 
to an Authorization Server
that, once being obtained, may be successfully passed from one client to 
another one without
the resource server to which it is intended being able to notice it.

Note that a /different/ format of a signed request would be one piece of 
a puzzle able to solve it.

======================================================================

ITEM 4

======================================================================

Hereafter is another topic both about the "client_id" and "collection 
minimization" which apparently do not related to each other
... but they do as it is explained below.


1) The draft states:

The signature MUST be validated against the appropriate key for that
"client_id" and algorithm.

I commented:

The important point is to provide guidance on how to map the client_id 
parameter with the appropriate key. There is none at the present time.


I suggested to add:

Identifying the appropriate key MUST be done according to section 6 of 
RFC 7515
and using the Registered Header Parameter Names defined in section 4.1 
of RFC 7515,
e.g. using the Header Parameters "jku", "jwk", "kid", "x5u", "x5c", 
"x5t", or "x5t#S256".

There was no comment/opinion from John about this proposal.


2)About "collection minimization"

The introduction states on page 4:

(d) (collection minimization) The request can be signed by a third party
attesting that the authorization request is compliant to certain
policy.

However, later on, there is the following explanation:

In addition, it allows requests to be prepared by a third party
so that a client application cannot request more permissions
than previously agreed.

John explained:

The third party indeed signs the request on behalf of the client as the 
result of verification that the permission is the same as previously 
agreed.

The value of `client_id` will be the requesting party.

The value of `iss` can be the third party.

But setting aside that, I guess your point actually is on the use of the 
word "request". Authorization request is the entire thing that travels
from the client and not a part of it, and that is a fair point. Having 
said that, I have a problem with your use of the word "verified". What 
about this?

(d) (collection minimization) The data being requested can be
attested by a third party that is compliant to collection
minimization principle.


3) Denis proposal to solve this comment:

After:

*The signature MUST be validated against the appropriate key for that 
"client_id" and algorithm.*

I suggest to add:

*Identifying the appropriate key MUST be done according to section 6 of 
RFC 7515
and using the Registered Header Parameter Names defined in section 4.1 
of RFC 7515,
e.g. using the Header Parameters "jku", "jwk", "kid", "x5u", "x5c", 
"x5t", or "x5t#S256".
That key may be either associated with the client_id which is a **string 
unique to the authorization
server representing the registration information originally provided by 
the end-user or
***associated *with a third party with which the authorization server 
has a trust relationship with it. ***

I also propose to change item d) in the following way:

(d) (collection minimization) The request can be signed by a third party
*rather than by an end-user *attesting that the authorization request
is compliant to certain policy. (...)

======================================================================

ITEM 5

======================================================================

One the following issue, I believe that I agree with John on the 
rational. However, John was unclear whether he accepted the proposed change
or an alternative one capturing the same concept.



The introduction states on page 4:

(a) (integrity protection) The request can be signed so that the 
integrity of the request can be checked;

This should be changed into:

(a) (integrity protection) The request can be authenticated either using 
a digital signature or using encryption under a secret key
so that the integrity of the request can be checked;

Reject.

This paragraph is talking about the integrity protection and not the 
source authentication.

And even for source authentication, saying that encryption under a 
secret key is not accurate as it was discussed earlier in the WG mail.

I am not sure if "Introduction" needs to state everything that is 
explained later. The idea of introduction probably is to give main points.
The list is not an exhaustive list of the benefit of using JWT as the 
authorization request format. For example, being able to encrypt
the request, which is not listed there, has an advantage of preventing 
MITB to eavesdrop the request. So I think it is ok as is.

Integrity protection cannot be verified without knowing the source of 
the information.

Using encryption (which supports at the same time an integrity service 
when secret keys are being used) is another way to be able to check the 
integrity of the request.

So I maintain may comment.


John: I think the issue is that if you encrypt with a asymmetric 
algorithm then the receiver has no idea who encrypted it.

Denis response: That is correct.

John: If encrypted with a symmetric key (not secret key) then you know 
that it came from someone who has access to that key. That works because 
we only support AEAD encryption.

Denis response: That is correct (/except than for me, since a symmetric 
key is a perfect synonym for a secret key/) :-)

John: You can use asymmetric encryption but you need to sign first if 
you want to know who it is from.

Denis response: It does not matter.

My proposal is to change the sentence into:

(a) (integrity protection) The request can be authenticated either using 
a digital signature or using encryption
under a /symmetric/ key so that the integrity of the request can be checked;

If you believe something should be changed in that proposal, please make 
another proposal.

======================================================================

ITEM 6

======================================================================

10. Section 11.1 states:

*11.1. Collection limitation

*

*When the Client is being granted access to a protected resource**
containing personal data, the Client SHOULD limit the collection of
personal data to that which is within the bounds of applicable law
    and strictly necessary for the specified purpose(s).*

  The /presentation/ of personal data should be limited whether or not 
the protected resource contains personal data.


We have trouble to understand each other.

1° This condition applies at the time of the request, not at the time of 
the granting.

2° The protected resource may contain either personal data or public 
data or both, so there is no need to specify "personal data".

3° Personal data is /presented /by the client, it is not /collected/.


In blue, you have the changes I propose:

*When the Client requests an access to a protected resource containing
personal data, the Client SHOULD limit the presentation of personal
data to that which is within the bounds of applicable law and strictly 
necessary
for the specified purpose(s).*

======================================================================

ITEM 7

======================================================================

John: This specification draws from OpenID Connect for some examples of 
extension parameters such as nonce.

On page 16 the text states:

*The following is an example of the Claims in a Request Object before*

*base64url encoding and signing.Note that it includes extension*

*variables such as "nonce" and "max_age".*

The key point is whether it is appropriate */in the main body of this 
document/ *to provide examples that include parameters
such as "nonce" and "max_age" that are not described in any RFC. The 
text does not even indicate where these extensions
are coming from. It would be more appropriate to use extensions that are 
defined in IETF RFCs.

Since the replay protection of the request MUST be achieved, remove 
*"nonce": "n-0S6_WzA2Mj**"*and replace it with:

*   "iat": 1487354400*

*   "rdn": 7945123 *

remove: *"max_age": 86400*

*
*

and finally remove: *N**ote that it includes extension**variables such 
as "nonce" and "max_age".

*

Denis



> Hi Denis,
>
> Thought John's response went to you as well but apparently not.
>
> My replies inline:
>
> On Fri, Feb 10, 2017 at 6:15 AM, Denis  > wrote:
>
>     Hi Nat,
>
>     My replies to your proposed disposition of comments are embedded
>     in the text.
>
> [snip]
>
>>          Section 4 states:
>>
>>         *A Request Object (Section 2.1) is used to provide authorization
>>         request parameters for an OAuth 2.0 authorization request.It
>>         contains OAuth 2.0 [RFC6749] authorization request parameters
>>         including extension parameters**.*
>>
>>         RFC 6749 contains 75 pages, but does not contain a single
>>         occurrence of the wording "authorization request parameter"
>>         nor of "extension parameter".
>>         There should be either references to one or more specific
>>         sections of this document or, even better, a list of the
>>         mandatory/recommended/possible
>>         authorization request parameters as well as a list of
>>         mandatory/recommended/possible extension parameters should be
>>         included in this document.
>>
>>         A clear distinction should be made between the parameters
>>         used to authenticate the request and the other ones.
>>
>>
>>     Reject.
>>     There are 4 flows in RFC6749. In each flow, there is a
>>     sub-section dedicated to the Authorization request.
>>     In them, the parameters used in the authorization request are
>>     very clearly indicated. For example,
>>
>>
>>             4.1.1
>>             .
>>             Authorization Request
>>
>>
>>
>>         The client constructs the request URI by adding the following
>>         parameters to the query component of the authorization endpoint URI ...
>>     It is very difficult to miss.
>>
>>     Then, the possibility for the extension parameters are discussed
>>     in 8.2. Needless to say, those extension parameters are going to
>>     be discussed in other specifications.
>>     Thus, it would be misleading just to say the parameters defined
>>     in 4.1.1, 4.2.1, etc.
>>     As an editor, I feel better with the current language because it
>>     is at least not wrong nor misleading.
>
>     draft-ietf-oauth-jwsreq-11states on page 7.
>
>     To sign, JSON Web Signature (JWS) [RFC7515] is used.The result is a
>
>     JWS signed JWT [RFC7519].If signed, the Authorization Request
>
>     Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience)
>
>     as members, with their semantics being the same as defined in the JWT
>
>     [RFC7519] specification.
>
>     This should be changed into:
>
>     To sign, JSON Web Signature (JWS) [RFC7515] is used.The result is a
>
>     JWS signed JWT [RFC7519].If signed, the Authorization Request
>
>     Object *MUST contain a client_id parameter* and SHOULD contain a
>     "iss" (issuer) *parameter* and an "aud" (audience) *parameter*, with
>     their semantics being the same as defined in the JWT RFC7519]
>     specification.
>
>  I am kind of ok with the proposed text but if we do you want to 
> single out `client_id`, perhpas a reason should be added.
> There are other REQIURED parameters in the Auhtorization Request 
> defined in RFC6749, you know.
>
>     In section 5.2. Message Signature or MAC Validation, the text states:
>
>     When validating a JWS, the following steps are performed.
>
>     (...)
>
>     See Section 10.6 for security considerations on algorithm
>
>     validation.
>
>     There is no section 10.6 in this document. It seems to be section 10.3
>
>     Anyway, it is not the right place to place requirements in a
>     security considerations section and the appropriate text
>     should be moved in the main body of the document.
>
>
> Sorry, I cannot find the text you are refering to.
>
>     RFC 6749 states in clause 4.Obtaining Authorization on page
>
>     6.2.JWS Signed Request Object
>
>     To perform JWS Signature Validation, the "alg" Header Parameter in
>
>     the JOSE Header MUST match the value of the pre-registered algorithm.
>
>     The signature MUST be validated against the appropriate key for that
>
>     "client_id" and algorithm.
>
>     The important point is to provide guidance on how to map the
>     client_idparameter with the appropriate key.
>     There is none at the present time.
>
>     Add:
>
>     Identifying the appropriate key MUST be done according to section 6
>     of RFC 7515 and using the Registered Header Parameter Names defined
>     in section 4.1 of RFC 7515, e.g. using the Header Parameters "jku",
>     "jwk", "kid", "x5u", "x5c", "x5t", or "x5t#S256".
>
>
>>     4. The introduction states on page 4:
>>
>>              (a) (integrity protection) The request can be signed so
>>         that the integrity of the request can be checked;
>>
>>         This should be changed into:
>>
>>              (a) (integrity protection) The request can be
>>         authenticated either using a digital signature or using
>>         encryption under a secret key
>>                   so that the integrity of the request can be checked;
>>
>>
>>     Reject.
>>     This paragraph is talking about the integrity protection and not
>>     the source authentication.
>>     And even for source authentication, saying that encryption under
>>     a secret key is not accurate as it was discussed earlier in the
>>     WG mail.
>>
>>     I am not sure if "Introduction" needs to state everything that is
>>     explained later. The idea of introduction probably is to give
>>     main points. The list is not an exhaustive list of the benefit of
>>     using JWT as the authorization request format. For example, being
>>     able to encrypt the request, which is not listed there, has an
>>     advantage of preventing MITB to eavesdrop the request. So I think
>>     it is ok as is.
>>
>     Integrity protection cannot be verified without knowing the source
>     of the information.
>
>     Using encryption (which supports at the same time
>     an integrity service when secret keys are being used) is another
>     way to be able to check the integrity of the request.
>
>     So I maintain may comment.
>
>
> I think the issue is that if you encrypt with a asymmetric algorithm 
> then the receiver has no idea who encrypted it.
> If encrypted with a symmetric key (not secret key) then you know that 
> it came from someone who has access to that key.
> That works because we only support AEAD encryption.
>
> You can use asymmetric encryption but you need to sign first if you 
> want to know who it is from.
>
>
>>     5. The introduction states on page 4:
>>
>>         (d) (collection minimization) The request can be *signed* by
>>         a third party attesting that the authorization request is
>>         compliant tocertain policy.
>>
>>         The request is not /signed/ by a third party.
>>
>>         However, later on, there is the following explanation:
>>
>>         In addition, it allows requests to be prepared by a third
>>         party so that a client application cannot request
>>            more permissions than previously agreed.
>>
>>          If it is the intent, the sentence should be rephrased as:
>>
>>         (d) (collection minimization) The request can be *verified*
>>         by a third party attesting that the authorization request is
>>         compliant tocertain policy.
>>
>>     Reject
>>     The third party indeed signs the request on behalf of the client
>>     as the result of verification that the permission is the same as
>>     previously agreed.
>
>     If it were the case, the client_id would indicate the name of the
>     third party and the name of the user would be missing (or vice versa).
>
>
> The value of `client_id` will be the requesting party.
> The value of `iss` can be the third party.
> But setting aside that, I guess your point actually is on the use of 
> the word "request". Authorization request is the entire thing that 
> travels from the client and not a part of it, and that is a fair 
> point. Having said that, I have a problem with your use of the word 
> "verified". What about this?
>>
>>     (d) (collection minimization) The data being requested can be
>>     *attested *by a third party that is compliant to collection
>>     minimization principle.
>>
>
>
>>          6. Section 10.1. the text states:
>>
>>         *When sending the authorization request object through "request"
>>         parameter, it MUST either be signed using JWS [RFC7515] or
>>         encrypted
>>         using JWE [RFC7516] with then considered appropriate algorithm.*
>>
>>          The wording"with then considered appropriate algorithm"is
>>         too vague. This should be changed into:
>>
>>         *When sending the authorization request object through "request"
>>         parameter, it MUST either be signed using JWS [RFC7515] or
>>         encrypted
>>         using JWE [RFC7516] using a symmetric key algorithm.*
>>
>>         Reject.
>>
>>     In the above sentence, "*with then considered appropriate
>>     algorithm*"  applies both on JWS and JWE.
>>     The intent of the phrase is that a vulnerable algorithm should
>>     not be used.
>>
>>     Also, I do not understand why the algorithm has to be symmetric
>>     key algorithm.
>
>     Maybe, this explains why you didn't understand the previous
>     comment. With public key encryption, it is not possible to
>     authenticate
>     the source of the request, while it is possible with secret key
>     encryption when the encrypted data includes a cryptographic checksum
>     like a hash value and an error propagation method for the
>     encryption algorithm.
>
>
> I understand this. My point is that this subsection is not talking 
> about what you just stated. This is a security consideration pointing 
> out that an alogrithm which has not become vulnerable must be used.
>
> What you describe should instead go below the list (a)(b)(c) in 
> section 5 or section 10.3.
> "when symmetric keys are being used" probably is a bit too open to 
> interpretation. John is now creating a text on it.
>
>     So I maintain my comment.
>
>
>>          7. Section 10.2 states:
>>
>>         This means that the request object is going to be prepared
>>         fresh each
>>         time an authorization request is madeand caching cannot be used.
>>
>>          What are the implications ? Is it required/recommended to
>>         use a nonce ? The text should be made clearer.
>>
>>     Reject.
>>     The implication is given right after the sentence. There is no
>>     variable called "nonce" in RFC6749. Since this document is just
>>     defining
>>     another encoding method for OAuth 2.0 authorization request as a
>>     framework, it does not mandate these.
>>     An extension specification should define those requirements.
>
>     Note that this section belongs to the security considerations
>     section which SHOULD NOT be normative and should only provide
>     guidance.
>
>     The sentence right after is the following:
>
>     It has a performance disadvantage, but where such disadvantage is
>
>     permissible, it should be considered.
>
>     It does not provide any guidance.
>
>
> Does it not? It is providing a guidance that the implementation should 
> consider not using cached request and create the request afresh each 
> time so that the entire request can be signed etc.
>
>     The key point is that a parameter able to detect replay needs to
>     be included in the request. This should be indicated in the
>     normative part.
>
>
> This security consideration is not about the replay attack but request 
> tampering.
>
>     It is unfortunate that RFC 7515 has not addressed replay
>     protection of JWS and only mentions the problem is section 10.10
>     which is in the
>     security considerations section. Here it is:
>
>     10.10.Replay Protection
>
>     While not directly in scope for this specification, note that
>
>     applications using JWS (or JWE) objects can thwart replay attacks by
>
>     including a unique message identifier as integrity-protected content
>
>     in the JWS (or JWE) message and having the recipient verify that the
>
>     message has not been previously received or acted upon.
>
>     The text on page 7 should be changed into:
>
>     To sign, JSON Web Signature (JWS) [RFC7515] is used.The result is a
>     JWS signed JWT [RFC7519].If signed, the Authorization Request
>     Object *MUST contain a client_id parameter* *and a "nonce"*
>     *extension
>     **parameter* *allowing to detect replay attacks *and SHOULD
>     contain an "iss"
>     (issuer) *parameter* and an "aud" (audience) *parameter*, with their
>     semantics being the same as defined in the JWT specification[RFC7519].
>
>     Note that Page 7 uses the "nonce" parameter in the example.
>
>
> I agree that inclusion of nonce etc. to thwart the replay attack has 
> to be done in the normative section and not in the security 
> consideration.
> Having said that, as I stated before, this specification is just 
> defining another encoding for RFC6749. As the result, the replay 
> protection etc. has to be deferred to an extension spec, such as OIDC.
>
>
>         JSON Web Token Claims are listed at:
>         https://www.iana.org/assignments/jwt/jwt.xhtml
>         
>
>     "Nonce" is mentioned in OpenID Connect Core 1.0 incorporating
>     errata set 1.
>
>     It is described as :
>
>     nonce
>
>     	
>
>     Value used to associate a Client session with an ID Token
>
>
>     This is too restrictive since now a nonce should be included in a
>     JWS token.
>
>     The registration is as follows:
>
>       * Parameter name: nonce
>       * Parameter usage location: Authorization Request
>       * Change controller: OpenID Foundation Artifact Binding Working
>         Group - openid-specs-ab@lists.openid.net
>         
>       * Specification document(s): Section 3.1.2
>         of
>         this document
>       * Related information: None
>
>
>     Section 3.1.2 states:
>
>
>           3.1.2.  Authorization Endpoint
>
>     The Authorization Endpoint performs Authentication of the
>     End-User. This is done by sending the User Agent to the
>     Authorization Server's
>     Authorization Endpoint for Authentication and Authorization, using
>     request parameters defined by OAuth 2.0 and additional parameters
>     and parameter values defined by OpenID Connect.
>
>     Communication with the Authorization Endpoint MUST utilize TLS.
>     See Section 16.17
>     for
>     more information on using TLS
>
>     This has nothing to do with the nonce. Hence the nonce
>     registration information has been badly defined.
>
>     The OpenID specification also states:
>
>
>     "The Client SHOULD check the noncevalue for replay attacks. The
>     precise method for detecting replay attacks is Client specific".
>
>     This does not allow to interoperate.
>
>     Rather than correcting the registration information in the OpenID
>     specification, it would be better to suppress it from the OpenID
>     specification
>     and incorporate it within an IETF RFC.
>
>
> Out of scope for this specification.
> Also, you should discuss something on OIDC on a sperarate list, not here.
>
>     In order to avoid nonces to be kept in a memory for ever, a good
>     practice is to split the nonce in two parts:
>
>       * one of them includes a UTC NumericDate using the format
>         defined in RFC 7519,and
>       * the other one includes a random number.
>
>
>     In this way only recent nonces (e.g. received during the last 5
>     minutes) need to be kept in memory.
>     Three or fourbytes for the random number will be sufficient.
>
>     In order to *allow for interoperability,* a format should be
>     specified.
>
>
>     I propose a NumericDate defining the UTC time concatenated with a
>     random number with three bytes.
>
>     "Nonce" has not been officially registered by IANA. An IANA
>     Considerations section should be added in draft-ietf-oauth-jwsreq-*
>     *to register the "nonce" parameter.
>
>
> Everything related to nonce is out of scope. You should write a new I-D.
>
>     On page 14, section 6.2., after the previous proposed text which is:
>
>     Identifying the appropriate key MUST be done according to section 6
>     of RFC 7515 and using the Registered Header Parameter Names defined
>     in section 4.1 of RFC 7515, e.g. using the Header Parameters "jku",
>     "jwk", "kid", "x5u", "x5c", "x5t", or "x5t#S256".
>
>     I proposed to add the following text:
>
>     To perform JWS Signature Validation, the "nonce" Header Parameter in
>
>     the JOSE Header MUST be present and MUST be checked to verify that
>     the signed request is not the replay of a previous signed request.
>
>     A section defining the nonce parameter should be added.
>
>
> [snip]
>
>
>>          9. Section 10.3 states at its very end:
>>
>>         An extension specification
>>         should be created as a preventive measure to address potential
>>         vulnerabilities that have not yet been identified.
>>
>>
>>         Writing a document for vulnerabilities that have not yet been
>>         identified is speculative. It would rather be better
>>         either to remove this sentence or to explain what is meant by it.
>>
>>     Reject.
>>     It is referring to the first paragraph of the sub-section. Also,
>>     precaution when security is in question is a good thing.
>
>     This sentence is simply useless and thus should be deleted. Hence,
>     I maintain this comment.
>
>
> Agree to disagree.
>
>
>>         10. Section 11.1 states:
>>
>>         *11.1.Collection limitation*
>>
>>         *When the Client is being granted access to a protected resource
>>         containing personal data, the Client SHOULD limit the
>>         collection of
>>         personal data to that which is within the bounds of
>>         applicable law
>>         and strictly necessary for the specified purpose(s).***
>>
>>          The /presentation/ of personal data should be limited
>>         whether or not the protected resource contains personal data.
>>
>>         It is proposed to change this text into:
>>
>>         *When the Client requests an access to a protected resource,
>>         the Client
>>         SHOULD limit the presentation of personal data to that which
>>         is within
>>         the bounds of applicable law and strictly necessary for the
>>         specified
>>         purpose(s).*
>>
>>     Reject.
>>     You are not getting what OAuth does. The party that holds
>>     personal data is the authorization server / resource.
>>     It is not the client. The client is the party who is getting
>>     those "resources" which may contain personal data.
>>     Yes, the client can provide some personal data to the resource
>>     depending on what that resource endpoint is, but that is out of
>>     scope for OAuth.
>>     As far as OAuth is concerned, what is being sent from the client
>>     to the resource is the access token.
>
>     The dispute is whether the protected resource contains or not
>     personal data.
>     The data contained by the protected resource may well be public
>     data (or/and personal data).
>     It does not need to be only "personal data".
>
>     Hence, I maintain my comment.
>
>
> I do not understand your comment now. Your previous proposeal seems to 
> be unrelated to the above comment.
>
>
>>         **
>>
>>          11. Section 11.2.1 states:
>>
>>         11.2.1.Request Disclosure
>>
>>         This specification allows extension parameters.
>>
>>          It would be useful to name either all of them or some of
>>         them. RFC 6749 is not crystal clear about this.
>>
>>     Noted.
>>     RFC6749 only defines how to define extension parameters.
>>     This specification draws from OpenID Connect for some examples of
>>     extension parameters such as nonce.
>>     See section 4 for example.
>
>
>     See my earlier comments where client_id and nonce shall be mandatory.
>
>
>
> client_id is mandatory in RFC6749. Nonce is not defined in RFC6749 and 
> hence out of scope for this specification.
>
>     Denis
>
>
> [snip]
>
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en



--------------618BA1C5DDA1E51BA8BB3017
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Nat,

        

        Thank you for the forwarding of the detailed responses made by
        John.

        Instead of replying between the lines, I have
        grouped my concerns under 7 items that are detailed below.
      
======================================================================

      
                                                                     
          ITEM 1

      
======================================================================

      
RFC 6749 states in
          section 10.2 (from the
          security considerations section on page 54):

      
The authorization
          server SHOULD NOT process
          repeated authorization requests automatically 

          (without active resource owner
          interaction) without authenticating the client or relying on
          other measures 

          to
          ensure that the repeated request comes from the original
          client and not an
          impersonator.

      
With such a vague
          guidance that are dozens of
          possibilities, none of them is being defined. 

      
How would two
          implementations be able to
          interoperate ? The answer is simple: they can't. 

        

      
Nevertheless, replay protection of a Token Request
            should be addressed in
            the current draft and presently it isn't. 

          In order to address this concern,
          I make a proposal.

      
An Authorization
          Server should be able to
          "easily" check (i.e. without losing to much computing time in
          order
          to decrease 

          the efficiency of DoS attacks) whether a Token Request is a
          replay
          or not from a previous Token Request. 

      
ISO/IEC
          10181-2:1996 (Information technology --
          Open Systems Interconnection -- Security frameworks for open
          systems:
          

          Authentication framework) published more than 20 years ago
          defines two methods:
          the use of challenges or the use of unique numbers. 

        Unique numbers are
          also called
          "nonces" (as a contraction of "number once") but their
          meaning is fully different from the meaning made by 

          the OpenID Connect Core
          specification, since a unique number as defined in that
          specification is in
          fact a "challenge" as defined by ISO/IEC 10181-2.

      


          Hereafter is the definition of a nonce as
          defined in the OpenID Connect Core specification: 

      
 nonce
        

      
String
            value used to associate a Client session with an ID Token, and to
            mitigate replay attacks.
            The value is passed through unmodified 

            from the Authentication Request to the
            ID Token. If present in the ID Token, Clients MUST verify
            that the nonce Claim Value is equal to 

            µthe value of the nonce
            parameter sent in the Authentication Request. If present in
            the Authentication
            Request, Authorization Servers MUST 

            include a nonce Claim
            in the ID Token with the Claim Value being the nonce value
            sent in the
            Authentication Request. Authorization Servers 

            SHOULD perform no other
            processing on nonce values used.
            The nonce value is a case sensitive
            string. 

      


          A unique number (according to ISO/IEC 10181-2) is
          generated by a client and is used by a server to check the
          freshness of a
          request 

          without the need for the server to remember it more than a
          couple or a
          dozen of minutes. It is composed of a UTC time and a random
          number. 

          A unique number is
          generated by the client and checked by the Authorization
          Server. 

      
Similarly, in order to
            allow a Client to verify that the Access Token corresponds
            to the content of
            the Authorization Request,

        some data
          SHOULD be included in the Access Token.

      
The OpenID Connect
          Core specification has
          defined a "nonce" that allows to perform the second check, but
          not to
          perform the first one. 

      
In order to avoid
          the Authorization Server to
          remember unique numbers (as defined in ISO/IEC 10181-2) for
          ever, each Authorization
          Request needs 

          to contain a UTC time, so that unique numbers that are out of
          a time
          window (of, let us say, a couple or a dozen of minutes) can be
          removed 

          from the
          memory the Authorization Server.

      
Fortunately, RFC
          7519, Section 4.1.6 has defined
          "iat" which means "Issued At".

      
This
          means that the Authorization
          Request as defined in the draft specification SHALL contain a
          unique number that consists of 

          both a
          "iat" parameter and a random number. 

      
Let us call that
          second parameter
          "rdn" for "random number" and let us register it at IANA it within
            this future RFC as a being an int32,

          which is quite
          sufficient for the intended purpose.

      
 

      
rdn

      
      
      
Integer value
            used by a Client in an
            Authentication Request for two purposes. Firstly, when
            associated with a
            "iat" parameter, 

            to allow an Authorization Server to detect the
            replay of an Authentication Request and secondly to allow a
            Client to check 

            the
            freshness of an Access Token. In order to detect the replay
            of an
            Authentication Request, the Authorization Server MUST 

            be able to (a) use a
            local clock loosely synchronized with the UTC, and (b)
            construct a table where
            the "iat" parameter and 

            the "rdn" parameter from each
            well-formed and accepted Authentication Request are
            memorized. Only the
            "iat" parameters 

            and the "rdn" parameters received during a
            short time window (e.g. a couple or dozen of minutes) need
            to be memorized. 

      
      
      
 

      
      
      
After checking
            that the Authentication Request
            is well formed, its processing SHOULD continue by checking
            that the
            "iat" parameter. 

            If the "iat" parameters is outside the
            time window, the Authentication Request SHALL be discarded
            by the Authorization
            Server. 

            If the "iat" parameters is inside the time window, the
            Authorization Server SHALL check if the "iat" parameter
            associated
            

            with that "rdn" parameter are not already memorized in the
            table. If
            it is the case, the Authentication Request SHALL be
            discarded 

            by the
            Authorization Server. Otherwise, the Authentication Request
            is not a replay of
            a previous Authentication Request and 

            the processing of the Authentication
            Request SHOULD continue.

      
      
      
 

      
      
      
The
            value of the rdn parameter is passed
            through unmodified from the Authentication Request to the
            Authorization Server.
            

            It MAY be included in the Access Token by the Authorization
            Server. If present
            in the Access Token, Clients MUST verify 

            that the rdn Claim Value is equal to
            the value of the rdn parameter sent in the Authentication
            Request and if it is
            not the case, 

            the Access Token SHALL be discarded.

      
Note that this
          allows to optimize the number of
          parameters without the need to use the nonce parameter (as defined in
            the OpenID Connect Core
            specification)

          which is not defined in
          any RFC for the moment.

      
The end result of
          this argumentation is that the
          Authorization Request - as defined in this draft specification
          - 

            SHALL contain both an
            "iat" parameter and a "rdn" parameter. Please take a
          look at the next item before
          expressing a position on this item.

      
======================================================================

      
                                                                     
          ITEM 2

      
======================================================================

      
Nat: The implementer of this document needs
            to consult RFC6749 closely anyway
            as all the verification requirements still holds, 

            so as an editor, I would
            rather keep it as it is. It is not "reader friendly" but
            cannot go
            wrong with the approach to just referencing RFC6749.

      
 

      
John: There
            are
            4 flows in RFC6749. In each flow, there is a sub-section
            dedicated to the
            Authorization request. 

            In them, the parameters used in the authorization
            request are very clearly indicated. (...) Thus, it would be
            misleading just to
            say 

            the parameters defined in 4.1.1, 4.2.1, etc. As an editor, I
            feel
            better with the current language because it is at least not
            wrong nor
            misleading.

      
 

      
I proposed:

      
 

      

        
  Object MUST contain a client_id
              parameter and SHOULD
            contain a

               "iss" (issuer) parameter and an "aud"
            (audience) parameter, with 

               their semantics being the same as defined in the JWT
            RFC7519] 

               specification. 

      

      
 

      
John:
             I am kind of ok with the proposed text but if we do you
            want to single
            out `client_id`, perhaps a reason should be added. 

            There are other REQUIRED
            parameters in the Authorization Request defined in RFC6749,
            you know.

      
The mandatory
          parameters to be included in the
          request should be identified. They are composed of :

      
(a)  
          the common denominator of the REQUIRED
          parameters defined in 4.1.1,
          4.2.1, etc, 

      
(b)  
          the parameters that are necessary to
          address the detection of the replay
          of previous well-formed requests, and

      
(c)  
          the parameters that are necessary to
          address the detection of the replay
          of a previous well-formed token.

      
The common
          denominator of the REQUIRED
          parameters defined in 4.1.1, 4.2.1, etc, is the client_id
          parameter (indicated
          as "REQUIRED").

      
The parameters
          that are necessary to address the
          detection of the two cases of replay are the "iat" and the
          "rdn" parameters.

      
 

      
As a reader, I feel better to know which
          parameters are REQUIRED,
          leaving other details in RFC 6749.

      
 

      
As a conclusion, the draft should indicate
          that the following parameters
          are always REQUIRED: client_id,
          iat and rdn.

      
Hence my proposal:

        

      
 

      

        
Object MUST contain
              a "client_id" parameter,
              i.e. a string
              representing the registration information
              

              provided by the end-user that is unique to the
              authorization server, an
              "iat" parameter and 

              a "rdn" parameter and SHOULD contain a
              "iss" (issuer) parameter and an "aud" (audience)
              parameter,
              

              with their semantics being the same as defined in the JWT
              [RFC7519]
              specification.

      

      
 

      
======================================================================

      
                                                                      ITEM
          3

      
======================================================================

      
 

      
Nat: ABC attack
            is out of scope for OAuth. It is not a new attack. The
            resource owner handing a
            bearer token 

            to another party willfully is not a threat in the bearer
            token
            model. 

      
      
      
 

      
      
      
Nat:
            ABC attack
            is out of scope of RFC 6749 and RFC6750. They can be dealt
            with in POP document
            but not this one. 

      
Denis: RFC 6749
          (The OAuth 2.0 Authorization
          Framework) has been published in October 2012. RFC 6819 (OAuth
          2.0 Threat Model
          and Security Considerations) 

          has been published in January 2013, hence after
          RFC 6749, so RFC 6749 could not reference RFC 6819. The
            carriage had been
            placed before the horse. 

      
RFC 6819
          implicitly talks about the ABC attack
          in section 5.1.6: 

      
5.1.6. 
          Access Tokens

      
   The
          following measures should be used to protect access tokens:

      
   (...).

      
   o  Ensure that
            client applications do not share tokens with 3rd parties.

      
 

      
You said: "They
            can be dealt with in POP
            document". 

          

      
Unfortunately, at the present time, this is
          not the case.

      
The key point is
          that none of the documents
          issued by the OAuth WG (neither by the Tokbind WG) indicates
          how to
          

          "Ensure that client applications do not share tokens with 3rd
          parties".

      
The charter of the
          Tokbind WG (unbearable) states
          (see: https://datatracker.ietf.org/wg/tokbind/charter)
          :

      
"It is a goal of
          this working group to
          enable defense against attacks that involve unauthorized
          replay of security
          tokens. 

          Other issues associated with the use of security tokens are
          out of scope".
          

      
 

      
However,
          draft-ietf-tokbind-protocol-13 (The Token Binding Protocol
          Version 1.0) issued
              yesterday explicitly states:

      
 

      
The Token Binding protocol does not
          prevent cooperating clients from

      
sharing a bound token. A client could
          intentionally export a bound

      
token with the corresponding Token Binding
          private key, or perform

      
signatures using this key on behalf of
          another client.

      
So neither the
          OAuth WG nor the TokBind WG have,
          at this time, a draft that is potentially able to counter the
          ABC attack.

      
So saying that the
          "ABC attack is out of
          scope for OAuth" is not the right wording. 

          Saying that the "ABC attack has not
            been taken into consideration for OAuth
            2.0" is a fact. 

          That fact should not be hidden in the current
          draft. 

      
Since it is
          unlikely that RFC 6819 will be soon
          replaced by another RFC, it is necessary to mention that
          threat in the security
          considerations section. 

          This does not mean that this threat shall be solved in
          the current draft, but readers should be aware that the ABC
          attack is not countered
          using this draft. 

      
A text along the
          following one should be added
          into the security consideration section:

      
 

      
In case of a cooperation between clients,
          the format of the JWT Secured
          Authorization Request 

          described in this document does not prevent a client from
          asking a token to an Authorization Server 

          that, once being obtained, may be
          successfully passed from one client to another one without 

          the resource server
          to which it is intended being able to notice it.

      
Note that a different
          format of a signed request
          would be one piece of a puzzle able to solve it.

      
======================================================================

      
                                                                     
          ITEM 4

      
======================================================================

      
Hereafter is
          another topic both about the "client_id"
          and "collection minimization" which apparently do not related
          to each
          other

          ... but they do as it is explained below. 
          

      


        

      
1) The draft
          states:

      
The
          signature MUST
          be validated against the appropriate key for that

          "client_id" and algorithm.

      
I
          commented:

      
The important point is to provide guidance
          on how to map the client_id
          parameter with the appropriate key. There is none at the
          present time.

      


        

      
I
          suggested to
          add:

      
Identifying the appropriate key MUST be
          done according to section 6 of
          RFC 7515 

          and using the Registered Header Parameter Names defined in
          section 4.1
          of RFC 7515, 

          e.g. using the Header Parameters "jku", "jwk",
          "kid", "x5u", "x5c", "x5t", or
          "x5t#S256".

      
There was no
          comment/opinion from John about
          this proposal.

      


        

      
2)  About
          "collection minimization"

      
The introduction
          states on page 4:

      
   (d)
          (collection minimization) The request
          can be signed by a third party 

                 attesting that
          the authorization
          request is compliant to certain 

                 policy.

      
However, later on,
          there is the following
          explanation:

      
   In
          addition, it allows requests to be
          prepared by a third party 

             so that a client
          application cannot
          request more permissions 

             than previously
          agreed. 

      
John explained: 

      
The third party
          indeed signs the request on
          behalf of the client as the result of verification that the
          permission is the
          same as previously agreed. 

      
The value of
          `client_id` will be the requesting
          party. 

      
The value of `iss`
          can be the third party. 

      
But setting aside
          that, I guess your point
          actually is on the use of the word "request". Authorization
          request
          is the entire thing that travels 

          from the client and not a part of it, and that
          is a fair point. Having said that, I have a problem with your
          use of the word
          "verified". What about this? 

      
   (d)
          (collection minimization) The data
          being requested can be 

                 attested by a
          third party that is
          compliant to collection 

                 minimization
          principle.  

      


          3) Denis proposal to solve this comment:

      
After:

      
The
            signature MUST be validated against the appropriate key for
            that
            "client_id" and algorithm.

      
I
          suggest to add:

          

          

      
Identifying the
            appropriate key MUST be done according
            to section 6 of RFC 7515 

            and using the Registered Header Parameter Names
            defined in section 4.1 of RFC 7515, 

            e.g. using the Header Parameters
            "jku", "jwk", "kid", "x5u",
            "x5c", "x5t", or "x5t#S256". 
              

            That key may be either associated with the
            client_id which is a string unique to the
            authorization 

            server representing
            the registration information originally provided by the
            end-user or 

          associated with
            a
            third party with which the authorization server has a trust
            relationship with
            it. 

      
I also propose to
          change item d) in the
          following way:
          

      
   (d)
          (collection minimization) The request
          can be signed by a third party 

                 rather
              than by an end-user attesting that the
          authorization request 

                 is compliant to
          certain policy.
          (...)

      
 

      
======================================================================

      
                                                                     
          ITEM 5

      
======================================================================

      
 

      
One the following issue, I believe that I
          agree with John on the
          rational. However, John was unclear whether he accepted the
          proposed change 

          or
          an alternative one capturing the same concept.

      


      

      


        

      

        
The
              introduction states on page 4:

      

      

        
    
              (a) (integrity protection) The request can be signed so
              that the integrity of
              the request can be checked ; 

        
 

        
This should be
              changed into:

        
 

        
    
              (a) (integrity protection) The request can be
              authenticated either using a
              digital signature or using encryption under a secret key 

                     
              so that the integrity of the request can be checked
            ;

      

      

        
Reject. 

        
This paragraph is talking about the
              integrity protection and not the source authentication. 

        
        
        
And even for source authentication,
              saying that encryption under a secret key is not accurate
              as it was discussed
              earlier in the WG mail. 

        
        
        
I am not sure if
              "Introduction" needs to state everything that is explained
              later. The
              idea of introduction probably is to give main points. 

              The list is not an
              exhaustive list of the benefit of using JWT as the
              authorization request
              format. For example, being able to encrypt 

              the request, which is not listed
              there, has an advantage of preventing MITB to eavesdrop
              the request. So I think
              it is ok as is. 

              

            

      

      

        
Integrity protection cannot
            be verified without knowing the source of the information. 

            

            

        
Using encryption (which
            supports at the same time an integrity service when secret
            keys are being used)
            is another way to be able to check the integrity of the
            request. 

        
So I maintain may comment.

      

      


        

      
John:
          I think the issue is that if
          you encrypt with a asymmetric algorithm then the receiver has
          no idea who
          encrypted it. 

      
 

      
Denis
          response: That is correct.

      
 

      
John:
          If encrypted with a
          symmetric key (not secret key) then you know that it came from
          someone who has
          access to that key. That works because we only support AEAD
          encryption.

      
 

      
Denis
          response: That is correct (except
            than for me, since a symmetric key is a perfect synonym for
            a secret key) :-)

      
 

      
John:
          You can use asymmetric
          encryption but you need to sign first if you want to know who
          it is from.

      
 

      
Denis response: It does not matter. 

      
 

      
My proposal is to change the sentence
          into:

      
 

      
(a) (integrity
            protection) The request can be
            authenticated either using a digital signature or using
            encryption 

            under a symmetric
            key so that the integrity of the
            request can be checked ;

      
 

      
If you believe
            something should be changed in that proposal, please make
            another proposal.

      
 

      
======================================================================

      
                                                                      ITEM
          6

      
======================================================================

      
 

      

        
10.
              Section 11.1 states:

              

            

        
 11.1. 
                Collection limitation

                

              

      

      

        
   
                When the Client is being
                  granted access to a
                protected resource

                 containing personal data,
                the Client SHOULD limit the
                collection of

                
                personal data to
                that which is within the bounds of applicable law

                 and
                strictly
                necessary for the specified purpose(s).

        
 

      

      

        
 The
              presentation of
              personal data should be limited whether or not the
              protected resource contains
              personal data. 

                   

      

      


          We have trouble to understand each other.

      
1° This condition
          applies at the time of the
          request, not at the time of the granting.

      
2° The protected
            resource may contain either
            personal data or public data or both, so there is no need to
            specify
            "personal data".

      
3° Personal data
            is presented by the client, it
            is not collected.

      


          In blue, you have the changes I propose:

      
 

      

        
When
                the Client requests an
                access to a protected resource containing 

                    personal data, the Client SHOULD limit
                the presentation
                of personal 

                data to that which is within the bounds of applicable
                law and strictly
                necessary 

                for the specified purpose(s).

      

      
 

      
======================================================================

      
                                                                     
          ITEM 7

      
======================================================================

      
 

      
John: This specification draws
            from OpenID Connect for some examples of
            extension parameters such as nonce.

      
On page 16 the
          text states:

      
 

      
   The
            following is an example of the Claims in a Request Object
            before

      
   base64url
            encoding and signing.  Note
            that it
            includes extension

      
   variables
            such as "nonce" and "max_age".

      
The key point is
          whether it is appropriate in
              the main body of this document to provide
          examples that include
          parameters 

          such as "nonce" and "max_age" that are not
          described in any RFC. The text does not even indicate where
          these
          extensions 

          are coming from. It would be more appropriate to use
          extensions that are defined in IETF RFCs.

      
Since the replay
            protection of the request MUST be
            achieved, remove "nonce":
            "n-0S6_WzA2Mj" and replace it
          with:

      
   "iat": 1487354400

      

      
   "rdn":
            7945123 

      
remove: "max_age":
            86400

      


          

      and finally remove:  Note
          that it
          includes extension variables
          such as "nonce" and "max_age".

          

        
      
Denis

      


        

      
      
      
      
      
      

    

    

      
Hi Denis, 
        


        

        
Thought John's response went to you as well but apparently
          not. 

        


        

        
My replies inline: 

        


          
On Fri, Feb 10, 2017 at 6:15 AM,
            Denis <denis.ietf@free.fr>
            wrote:

            

              

                
Hi
                  Nat,

                  

                  My replies to your proposed disposition of comments
                  are embedded in the text.

                

              

            

            
[snip] 

            

              

                

                  

                    

                      

                        

                          

                            
 Section 4 states:

                            
   
                                  A Request Object (Section 2.1)
                                  is used to provide authorization

                                    
                                  request parameters for an OAuth
                                  2.0 authorization request. 
                                  It

                                       contains OAuth 2.0
                                  [RFC6749] authorization request
                                  parameters

                                    
                                  including extension parameters. 
                                  

                            
RFC 6749 contains 75 pages,
                                but does not contain a single occurrence
                                of the wording "authorization request
                                parameter" nor of "extension parameter".
                                

                                There should be either references to one
                                or more specific sections of this
                                document or, even better, a list of the
                                mandatory/recommended/possible 

                                authorization request parameters as well
                                as a list of
                                mandatory/recommended/possible extension
                                parameters should be included in this
                                document.

                            
A clear
                                distinction should be made between the
                                parameters used to authenticate the
                                request and the other ones.

                          

                        

                      

                      


                      

                      
Reject. 

                      
There are 4 flows in RFC6749. In each flow,
                        there is a sub-section dedicated to the
                        Authorization request. 

                      
In them, the parameters used in the
                        authorization request are very clearly
                        indicated. For example, 

                      


                      

                      

                        
4.1.1.  Authorization Request


   The client constructs the request URI by adding the following
   parameters to the query component of the authorization endpoint URI ... 

                        It is very difficult to miss. 

                      


                      

                      
Then, the possibility for the extension
                        parameters are discussed in 8.2. Needless to
                        say, those extension parameters are going to be
                        discussed in other specifications. 

                      
Thus, it would be misleading just to say the
                        parameters defined in 4.1.1, 4.2.1, etc. 

                      
As an editor, I feel better with the current
                        language because it is at least not wrong nor
                        misleading. 

                      

                    

                  

                

                

                
draft-ietf-oauth-jwsreq-11 states on page 7.

                
 

                
   To sign, JSON Web
                    Signature (JWS) [RFC7515] is used.  The
                    result is a

                
   JWS signed JWT
                    [RFC7519].  If signed, the
                    Authorization Request

                
   Object SHOULD contain
                    the Claims "iss" (issuer) and "aud" (audience)

                
   as members, with their
                    semantics being the same as defined in the JWT

                
   [RFC7519]
                    specification.

                
 

                
This should be changed into:

                
 

                
   To sign, JSON Web
                    Signature (JWS) [RFC7515] is used.  The
                    result is a

                
   JWS signed JWT
                    [RFC7519].  If signed, the
                    Authorization Request

                
   Object MUST
                      contain a client_id parameter and SHOULD
                    contain a

                       "iss" (issuer) parameter
                    and an "aud" (audience) parameter, with 

                       their semantics being the same as
                    defined in the JWT RFC7519] 

                       specification.

                
 

              

            

            
 I am kind of ok with the proposed text but if we do
              you want to single out `client_id`, perhpas a reason
              should be added. 

            
There are other REQIURED parameters in the
              Auhtorization Request defined in RFC6749, you know. 

            

              

                

                
In section 5.2. Message Signature or
                      MAC Validation, the text states:

                 
                
 

                 
                
   When validating a
                      JWS, the following steps are performed.

                 
                
 

                 
                
(...)

                 
                
       See Section 10.6
                      for security considerations on algorithm

                 
                
       validation.

                 
                
 

                 
                
There is no section 10.6 in this
                      document. It seems to be section 10.3

                 
                
Anyway, it is not the right place to
                      place requirements in a security considerations
                      section and the appropriate text 

                      should be moved in the main body of the document.

              

            

            


            

            
Sorry, I cannot find the text you are refering to. 

            
 

            

              

                

                 
                
 

                 
                
RFC 6749 states in clause 4.  Obtaining
                      Authorization on page 

                
 

                
6.2.  JWS Signed Request
                    Object

                
 

                
   To perform JWS
                    Signature Validation, the "alg" Header Parameter in

                
   the JOSE Header MUST
                    match the value of the pre-registered algorithm.

                
   The
                      signature MUST be validated against the
                      appropriate key for that

                
   "client_id" and
                    algorithm.

                
 

                
The important point is to provide
                      guidance on how to map the client_id parameter with the appropriate key.
                      

                      There is none at the present time.

                 
                
 

                 
                
Add:

                
 

                
   Identifying the
                    appropriate key MUST be done according to section 6
                    

                       of RFC 7515 and using the
                    Registered Header Parameter Names defined 

                       in section 4.1 of RFC 7515, e.g.
                    using the Header Parameters "jku", 

                       "jwk", "kid", "x5u", "x5c", "x5t",
                    or "x5t#S256".

                
 

                

                

                  

                    

                      
 4. The introduction states on
                          page 4:

                      

                        

                          

                            
 

                            
     (a) (integrity
                                protection) The request can be signed so
                                that the integrity of the request can be
                                checked
                                ; 

                            
 

                            
This should be changed
                                into:

                            
 

                            
     (a) (integrity
                                protection) The request can be
                                authenticated either using a digital
                                signature or using encryption under a
                                secret key 

                                          so that the integrity of the
                                request can be checked
                                ;

                          

                        

                      

                      


                      

                      
Reject. 

                      

                        
This paragraph is talking about the
                          integrity protection and not the source
                          authentication. 

                        
And even for source authentication, saying
                          that encryption under a secret key is not
                          accurate as it was discussed earlier in the WG
                          mail. 

                      

                      


                      

                      
I am not sure if "Introduction" needs to
                        state everything that is explained later. The
                        idea of introduction probably is to give main
                        points. The list is not an exhaustive list of
                        the benefit of using JWT as the authorization
                        request format. For example, being able to
                        encrypt the request, which is not listed there,
                        has an advantage of preventing MITB to eavesdrop
                        the request. So I think it is ok as is. 

                      


                      

                    

                  

                

                
Integrity protection cannot be verified
                    without knowing the source of the information. 

              

            

            

              

                
Using encryption (which supports at the
                    same time 

                    an integrity service when secret keys are being
                    used) is another way to be able to check the
                    integrity of the request. 

                
 

                
So I maintain may comment.

              

            

            


            

            
I
                think the issue is that if you encrypt with a asymmetric
                algorithm then the receiver has no idea who encrypted
                it. 
              
If
                encrypted with a symmetric key (not secret key) then you
                know that it came from someone who has access to that
                key. 

              
That
                works because we only support AEAD encryption.

              


              

              
You
                can use asymmetric encryption but you need to sign first
                if you want to know who it is from.

            

            
 

            

              

                


                  

                

                  

                    

                      
 5. The introduction states on
                          page 4:

                      

                        

                          

                            
 

                            
(d) (collection
                                minimization) The request can be signed
                                by a third party attesting that the
                                authorization request is compliant to certain policy.

                            
The request is
                                not signed
                                by a third party. 

                              

                          

                        

                      

                      

                        

                          

                            
However, later on, there is
                                the following explanation: 

                              

                            
  
                                In addition, it allows requests
                                to be prepared by a third party so that
                                a client application cannot request 

                                   more permissions than previously
                                agreed. 
                                

                            
 If it is the intent, the
                                sentence should be rephrased as: 

                              

                            
(d) (collection
                                minimization) The request can be verified
                                by a third party attesting that the
                                authorization request is compliant to certain policy. 

                              

                          

                        

                      

                      
Reject

                      
The third party indeed signs the request on
                        behalf of the client as the result of
                        verification that the permission is the same as
                        previously agreed.  

                      

                    

                  

                

                

                
If it were the case, the client_id
                    would indicate the name of the third party and the
                    name of the user would be missing (or vice versa).

              

            

            


            

            
The value of `client_id` will be the requesting party. 

            
The value of `iss` can be the third party. 

            
But setting aside that, I guess your point actually is
              on the use of the word "request". Authorization request is
              the entire thing that travels from the client and not a
              part of it, and that is a fair point. Having said that, I
              have a problem with your use of the word "verified". What
              about this? 

            

              

                

                  

                    

                      

                        

                          
(d) (collection
                                minimization) The data being requested
                                can be attested by a third party that is
                                compliant to collection
                                minimization principle.  

                        

                      

                    

                  

                

              

            

            

              

                


                

                

                

                  

                    

                      

                        

                          

                            

                            
 6. Section 10.1. the text
                                states: 

                              

                            
  
                                  When sending the authorization
                                  request object through "request"

                                    
                                  parameter, it MUST either be
                                  signed using JWS [RFC7515] or
                                  encrypted

                                    
                                  using JWE [RFC7516] with then
                                  considered appropriate algorithm.

                            
 The wording" with then considered
                                appropriate algorithm" is too vague.
                                This should be changed into:

                            
  
                                  When sending the authorization
                                  request object through "request"

                                    
                                  parameter, it MUST either be
                                  signed using JWS [RFC7515] or
                                  encrypted

                                    
                                  using JWE [RFC7516] using
                                    a symmetric key algorithm.

                            
 Reject. 

                          

                        

                      

                      
In the above sentence, "with then considered
                            appropriate algorithm"  applies
                        both on JWS and JWE. 

                      
The intent of the phrase is that a vulnerable
                        algorithm should not be used. 

                      


                      

                      
Also, I do not understand why the algorithm
                        has to be symmetric key algorithm. 

                      

                    

                  

                

                

                
Maybe, this explains why you didn't
                    understand the previous comment. With public key
                    encryption, it is not possible to authenticate 

                    the source of the request, while it is possible with
                    secret key encryption when the encrypted data
                    includes a cryptographic checksum 

                    like a hash value and an error propagation method
                    for the encryption algorithm.

              

            

            


            

            
I understand this. My point is that this subsection is
              not talking about what you just stated. This is a security
              consideration pointing out that an alogrithm which has not
              become vulnerable must be used. 

            


            

            
What you describe should instead go below the list
              (a)(b)(c) in section 5 or section 10.3. 

            
"when
                symmetric keys are being used" probably is a bit too
                open to interpretation. John is now creating a text on
                it. 

            
 

            

              

                

                
 

                
So I maintain my comment.

                

                

                

                  

                    

                      

                        

                          

                            

                            
 7. Section 10.2 states: 

                              

                            
  
                                This means that the request
                                object is going to be prepared
                                  fresh each

                                     time an authorization
                                request is made and caching cannot be
                                used. 
                                

                            
 What are the implications
                                ? Is it required/recommended to use a
                                nonce ? The text should be made clearer.
                              

                            

                          

                        

                      

                      
Reject. 

                      
The implication is given right after the
                        sentence. There is no variable called "nonce" in
                        RFC6749. Since this document is just defining 

                        another encoding method for OAuth 2.0
                        authorization request as a framework, it does
                        not mandate these. 

                        An extension specification should define those
                        requirements. 

                      

                    

                  

                

                

                
Note that this section belongs to the
                    security considerations section which SHOULD NOT be
                    normative and should only provide guidance. 

                
 

                
The sentence right after is the
                    following:

                
 

                
   It has a performance
                    disadvantage, but where such disadvantage is

                
   permissible, it should
                    be considered.

                
 

                
It does not provide any guidance.

              

            

            


            

            
Does it not? It is providing a guidance that the
              implementation should consider not using cached request
              and create the request afresh each time so that the entire
              request can be signed etc. 

            
 

            

              

                
 

                
 

                
The key point is that a parameter able
                    to detect replay needs to be included in the
                    request. This should be indicated in the normative
                    part. 

                  

              

            

            


            

            
This security consideration is not about the replay
              attack but request tampering. 

            


            

            

              

                
It is unfortunate that RFC 7515 has not
                    addressed replay protection of JWS and only mentions
                    the problem is section 10.10 which is in the 

                    security considerations section. Here it is: 

              

            

            

              

                

                
 

                
10.10.  Replay Protection

                
   While not directly in
                    scope for this specification, note that

                
   applications using JWS
                    (or JWE) objects can thwart replay attacks by

                
   including a unique
                    message identifier as integrity-protected content

                
   in the JWS (or JWE)
                    message and having the recipient verify that the

                
   message has not been
                    previously received or acted upon.

                
 

                
The text on page 7 should be changed
                    into:

                
 

                
   To sign, JSON Web
                    Signature (JWS) [RFC7515] is used.  The
                    result is a

                       JWS signed JWT [RFC7519].  If
                    signed, the Authorization Request

                       Object MUST contain a client_id
                      parameter and a "nonce" extension
                      

                       parameter allowing to detect replay attacks and SHOULD contain an "iss" 

                       (issuer) parameter and an
                    "aud" (audience) parameter, with their 

                       semantics being the same as defined
                    in the JWT specification[RFC7519].

                
 

                
Note that Page 7 uses the "nonce"
                    parameter in the example.

              

            

            


            

            

              
I agree that inclusion of nonce etc. to thwart the
                replay attack has to be done in the normative section
                and not in the security consideration. 

              
Having said that, as I stated before, this
                specification is just defining another encoding for
                RFC6749. As the result, the replay protection etc. has
                to be deferred to an extension spec, such as OIDC. 

              
 

            

            

              

                
 

                
JSON Web Token Claims are listed at: https://www.iana.org/assignments/jwt/jwt.xhtml

                
"Nonce" is mentioned in OpenID Connect
                    Core 1.0 incorporating errata set 1. 

                
 

                
It is described as :

                
 

                

                  
                    

                      
                        
nonce

                      		
                      
                        
Value
                            used to associate a Client session with an
                            ID Token

                      		
                    

                  
                

                


                  

                
This is too restrictive since now a
                    nonce should be included in a JWS token.

                
 

                
The registration is as follows:

                
    
                  
  • Parameter
                      name: nonce
                    
    • 
                  
  • Parameter
                      usage location: Authorization Request 
    • 
                  
  • Change
                      controller: OpenID Foundation Artifact Binding
                      Working Group - openid-specs-ab@lists.openid.net
                    
    • 
                  
  • Specification
                      document(s): Section 3.1.2 of this document 
    • 
                  
  • Related information: None
                    
    • 
                

                


                

              

            

            

              

                
 

                
Section 3.1.2 states:

                
3.1.2.  Authorization Endpoint

                
The
                    Authorization Endpoint performs Authentication of
                    the End-User. This is done by sending the User Agent
                    to the Authorization Server's 

                    Authorization Endpoint for Authentication and
                    Authorization, using request parameters defined by
                    OAuth 2.0 and additional parameters 

                    and parameter values defined by OpenID Connect. 

                
 

                
Communication
                    with the Authorization Endpoint MUST utilize TLS.
                    See Section 16.17 for more
                    information on using TLS

                
 

                
This has nothing to do with the nonce.
                    Hence the nonce registration information has been
                    badly defined. 

                
 

                
The OpenID specification also states:

                


                  

                
 

                
"The Client SHOULD
                      check the nonce value for replay attacks. The
                      precise method for detecting replay attacks is
                      Client specific".

                
 

                
This does not allow to interoperate.

                
 

                
Rather than correcting the registration
                    information in the OpenID specification, it would be
                    better to suppress it from the OpenID specification
                    

                    and incorporate it within an IETF RFC.

              

            

            


            

            
Out of scope for this specification. 

            
Also, you should discuss something on OIDC on a
              sperarate list, not here. 

            
 

            

              

                

                
 

                
In order to avoid nonces to be kept in
                    a memory for ever, a good practice is to split the
                    nonce in two parts: 

                  

                
    
                  
  • one
                      of them includes a UTC NumericDate using the format
                        defined in RFC 7519, and 
    • 
                  
  • the
                      other one includes a random number. 
    
                    
    • 
                

                


                    In this way only recent nonces (e.g. received during
                    the last 5 minutes) need to be kept in memory. 

                    Three or four bytes for the random
                    number will be sufficient.

                
 

                
In order to allow for
                      interoperability, a format should be
                    specified.

                


                  

                
I propose a NumericDate defining the
                    UTC time concatenated with a random number with
                    three bytes.

                
 

                
"Nonce" has not been officially
                    registered by IANA. An IANA Considerations section
                    should be added in draft-ietf-oauth-jwsreq-
                        

                      to register the "nonce" parameter.

              

            

            


            

            
Everything related to nonce is out of scope. You should
              write a new I-D. 

            
 

            

              

                

                
 

                
On page 14, section 6.2., after the
                    previous proposed text which is:

                
 

                
   Identifying the
                    appropriate key MUST be done according to section 6
                    

                       of RFC 7515 and using the
                    Registered Header Parameter Names defined 

                       in section 4.1 of RFC 7515, e.g.
                    using the Header Parameters "jku", 

                       "jwk", "kid", "x5u", "x5c", "x5t",
                    or "x5t#S256".

                
 

                
I proposed to add the following text: 

                
 

                
   To perform JWS
                    Signature Validation, the "nonce" Header Parameter
                    in

                
   the
                    JOSE Header MUST be present and MUST be checked to
                    verify that 

                       the signed request is not the
                    replay of a previous signed request.

                
 

                A section defining the nonce
                  parameter should be added.

            

            


            

            
[snip] 

            

              


                

                  

                    

                      

                        

                          

                            
 9. Section 10.3 states at
                                its very end:

                            
   
                                An extension specification

                                  
                                should be created as a preventive
                                measure to address potential

                                  
                                vulnerabilities that have not yet
                                been identified.

                            


                              

                            
Writing a document for
                                vulnerabilities that have not yet been
                                identified is speculative. It would
                                rather be better 

                                either to remove this sentence or to
                                explain what is meant by it.

                          

                        

                      

                      
Reject. 

                      
It is referring to the first paragraph of the
                        sub-section. Also, precaution when security is
                        in question is a good thing. 
                          

                        

                    

                  

                

                

                
This sentence is simply useless and
                    thus should be deleted. Hence, I maintain this
                    comment.

                

              

            

            
Agree to disagree. 

            
 

            

              
 

                

                  

                    

                      

                        

                          

                            
10. Section 11.1 states:

                            
 11.1. 
                                  Collection limitation

                            
   
                                  When the Client is being
                                  granted access to a protected resource

                                    
                                  containing personal data, the
                                  Client SHOULD limit the collection of

                                    
                                  personal data to that which is
                                  within the bounds of applicable law

                                    
                                  and strictly necessary for the
                                  specified purpose(s).

                            
 The presentation
                                of personal data should be limited
                                whether or not the protected resource
                                contains personal data. 

                            

                          

                        

                      

                      

                        

                          

                            
It is proposed to change
                                this text into: 

                              

                            
  
                                  When the Client requests an
                                  access to a protected resource, the
                                  Client

                                    
                                  SHOULD limit the presentation
                                  of personal data to that which is
                                  within

                                    
                                  the bounds of applicable law
                                  and strictly necessary for the
                                  specified

                                    
                                  purpose(s).

                          

                        

                      

                      
Reject. 

                      
You are not getting what OAuth does. The
                        party that holds personal data is the
                        authorization server / resource. 

                      
It is not the client. The client is the party
                        who is getting those "resources" which may
                        contain personal data. 

                      
Yes, the client can provide some personal
                        data to the resource depending on what that
                        resource endpoint is, but that is out of scope
                        for OAuth. 

                      
As far as OAuth is concerned, what is being
                        sent from the client to the resource is the
                        access token. 

                      

                    

                  

                

                

                

                  
The dispute
                      is whether the protected
                        resource contains or not personal data. 

                        The data contained by the protected resource may
                        well be public data (or/and personal data). 

                        It does not need to be only "personal data".

                  
 

                  
Hence, I
                        maintain my comment.

                

                

              

            

            
I do not understand your comment now. Your previous
              proposeal seems to be unrelated to the above comment. 

            
 

            

              
 

                

                  

                    

                      

                        

                          

                            

                            
 11. Section 11.2.1 states:
                                

                              

                            
11.2.1. 
                                Request Disclosure 

                              

                            
  
                                This specification allows
                                extension parameters. 

                            
 It would be useful to name
                                either all of them or some of them. RFC
                                6749 is not crystal clear about this.

                          

                        

                      

                      
Noted. 

                      
RFC6749 only defines how to define extension
                        parameters. 

                      
This specification draws from OpenID Connect
                        for some examples of extension parameters such
                        as nonce. 

                      
See section 4 for example.  

                      

                    

                  

                

                


                    See my earlier comments where client_id and nonce
                    shall be mandatory.

                

              

            

            


            

            
client_id is mandatory in RFC6749. Nonce is not defined
              in RFC6749 and hence out of scope for this specification. 

            
 

            

              
 Denis

            

            


            

            
[snip] 

          

          


          

          -- 

          
Nat Sakimura (=nat)
            
Chairman, OpenID Foundation

              http://nat.sakimura.org/

              @_nat_en

          

        

      

    

    


    

  


--------------618BA1C5DDA1E51BA8BB3017--


From nobody Sat Feb 18 12:23:34 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90D11295C8; Sat, 18 Feb 2017 12:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbg2du4_Cyot; Sat, 18 Feb 2017 12:23:30 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D698129572; Sat, 18 Feb 2017 12:23:30 -0800 (PST)
Received: by mail-wm0-x236.google.com with SMTP id 196so15488133wmm.1; Sat, 18 Feb 2017 12:23:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SnzHu9LMalNHXwJY+2gT1Ugz5dfe064Yj5JL1vLLh4E=; b=k0PwSMWMLkY8B4Ung2PDnB1Dn+8HF6xUKutV9SHsXD9NOmqLX/2BB2HU2sBwmbg8gh NOz382N7TpVJjVdWWnhIV/p288TUC4HMhBHm7TEf5Kw+hXISLfHvyL8xWw7Xg70bODkT LBIhKUtGyoAabSvrLbMR2QHtDTt5xryuVQhSWAKPLsZhhbl5yFxENiwVYchPj11qaraG bfp09G5E3EZWiMZFbsTgfc8yjDKhf/KuYe7y9tB5v3xBxG/8nCgOMK8hB/HJio0HvJ8O ClZOSyZ7TJIoptc4Klhn6L9mVpbXCapezaeWnK1jeyMBkcLTncEquq3jR/ufkGQOL+n+ Yr8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SnzHu9LMalNHXwJY+2gT1Ugz5dfe064Yj5JL1vLLh4E=; b=dl0qxf4KbB/EjUoJy+w7IsjNdysdQ/gFEZWi/+gybO40ojd66SymDP2uvCGlmNSwA9 MV+Ca5eZFKtxK0XDvgGC48v61o2ycUL/kcEcRYcEHGqsruO09kO+DdpGzHsasToYC89w NaXx7W6Dk0gqIVkMrthTXSBKtOg+ighYf/bBmXo+dl3iLWZVtVq9MYwzM9l33de3noWB /LqI80/vLO1DTOqRPCqbE/3HTCfx0KWlIByVVByv8WxsLv481ou87tg+6EXF7I5CFxY9 HXgyRGBOGF1AQjj7ZEIg51DcoK3ldrRpY3zGu1U9gXczmhU6gL2fmT3Egj3SPFMuwh8f z7Pw==
X-Gm-Message-State: AMke39kUada1qdzLALcPVAZV+EawCl3Pg3lWF7p3ofPn8LjmnLn9raXRaPLEre17qbTdlR/aAqyps6sdV9duJA==
X-Received: by 10.28.15.2 with SMTP id 2mr11050576wmp.66.1487449408917; Sat, 18 Feb 2017 12:23:28 -0800 (PST)
MIME-Version: 1.0
References: <148720444007.31614.4351735589682369445.idtracker@ietfa.amsl.com>
In-Reply-To: <148720444007.31614.4351735589682369445.idtracker@ietfa.amsl.com>
From: Nat Sakimura 
Date: Sat, 18 Feb 2017 20:23:18 +0000
Message-ID: 
To: Stephen Farrell 
Content-Type: multipart/alternative; boundary=001a1146995ea3de370548d3cd90
Archived-At: 
Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth@ietf.org, oauth-chairs@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwsreq-12: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Feb 2017 20:23:33 -0000

--001a1146995ea3de370548d3cd90
Content-Type: text/plain; charset=UTF-8

Hi Stephen,

Thank you very much for your thoughtful comments.
My response (after discussing with John) inline:

On Thu, Feb 16, 2017 at 9:20 AM Stephen Farrell 
wrote:

> Stephen Farrell has entered the following ballot position for
> draft-ietf-oauth-jwsreq-12: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> - intro: "attacks... have been identified." yells out for a
> reference - it'd be a good bit better if implementers could
> easily find details of some such attacks, so I hope you add
> some refs here.
>

Will do.


>
> - section 3; WAP? Really? I'm surprised any WAP technology
> would still be in use, even on feature-phones. Do you really
> need this?
>

WAP/cHTML and the variation there of. It may not be truly WAP but it would
exemplify those. I could have said "limited capaibility browsers" but then
that would sound like something akin of mobile browsers on smartphones.


>
> - section 4: I think it will turn out to be an error to allow
> for mixing query parameters and protected parameters (in a
> Request Object) in a single request. Do you really need that
> level of flexibility? It'd be simpler and less likely to be
> attackable to insist that all parameters be in the Request
> Object if one is used. (See also section 11.2.1 below.)
>
> Right.
The benefit of the flexibility is not big and may not warrant the cost
associated with it.


> - section 10: Is there nothing to be said about the new
> indirection caused by the request_uri? I'd have thought there
> were some corner cases that'd warrant a mention, e.g. if some
> kind of deadlock or looping could happen, or if one client (in
> OAuth terms) could use a request_uri value as a way to attempt
> attacks (to be assisted by an innocent browser) against some
> resource owner.
>

Good point. I can think of several attack surfaces such as DoS attack to
the authorization server. I could not come up with an attack against the
resource owner for the time being though.


>
> - section 11: thanks for that, it's good.
>
> - section 11: Saying that an ISO thing is "good to follow" is
> quite weak IMO. (And is that ISO spec accessible? Hmm...  it
> seems that one needs to accept cookies to get it which is
> wonderfully ironic;-) If the authors have the energy, I'd
> suggest trying to find better guidance that's more publically
> available in a privacy-friendly manner. (Or just drop the ISO
> reference if 6973 is good enough.)
>
>
When I first put in the reference to 29100, I meant to write a fuller write
up using it as it would be useful for the orgaanizations implementing ISMS.
(Privacy extensions to ISMS are written based on 29100).
But I did not. I may just drop the reference as well since collection
minimization and disclosure minimization probably is self evident.

Best,

Nat

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

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a1146995ea3de370548d3cd90
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Hi Stephen,=C2=A0

Thank =
you very much for your thoughtful comments.=C2=A0
My response (af=
ter discussing with John) inline:=C2=A0

<=
div dir=3D"ltr">On Thu, Feb 16, 2017 at 9:20 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> wro=
te:
Stephen Farrell has entered the=
 following ballot position for

draft-ietf-oauth-jwsreq-12: No Objection



When responding, please keep the subject line intact and reply to all

email addresses included in the To and CC lines. (Feel free to cut this

introductory paragraph, however.)





Please refer to https://www.ietf.org/iesg=
/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.





The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-=
ietf-oauth-jwsreq/







----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------





- intro: "attacks... have been identified." yells out for a

reference - it'd be a good bit better if implementers could

easily find details of some such attacks, so I hope you add

some refs here.

Wil=
l do.=C2=A0
=C2=A0



- section 3; WAP? Really? I'm surprised any WAP technology

would still be in use, even on feature-phones. Do you really

need this?

WAP/cHTM=
L and the variation there of. It may not be truly WAP but it would exemplif=
y those. I could have said "limited capaibility browsers" but the=
n that would sound like something akin of mobile browsers on smartphones.=
=C2=A0
=C2=A0



- section 4: I think it will turn out to be an error to allow

for mixing query parameters and protected parameters (in a

Request Object) in a single request. Do you really need that

level of flexibility? It'd be simpler and less likely to be

attackable to insist that all parameters be in the Request

Object if one is used. (See also section 11.2.1 below.)


Right.=C2=A0
The benefi=
t of the flexibility is not big and may not warrant the cost associated wit=
h it.=C2=A0
=C2=A0

- section 10: Is there nothing to be said about the new

indirection caused by the request_uri? I'd have thought there

were some corner cases that'd warrant a mention, e.g. if some

kind of deadlock or looping could happen, or if one client (in

OAuth terms) could use a request_uri value as a way to attempt

attacks (to be assisted by an innocent browser) against some

resource owner.

Goo=
d point. I can think of several attack surfaces such as DoS attack to the a=
uthorization server. I could not come up with an attack against the resourc=
e owner for the time being though.=C2=A0
=C2=A0



- section 11: thanks for that, it's good.



- section 11: Saying that an ISO thing is "good to follow" is

quite weak IMO. (And is that ISO spec accessible? Hmm...=C2=A0 it

seems that one needs to accept cookies to get it which is

wonderfully ironic;-) If the authors have the energy, I'd

suggest trying to find better guidance that's more publically

available in a privacy-friendly manner. (Or just drop the ISO

reference if 6973 is good enough.)



When I first put i=
n the reference to 29100, I meant to write a fuller write up using it as it=
 would be useful for the orgaanizations implementing ISMS. (Privacy extensi=
ons to ISMS are written based on 29100).=C2=A0
But I did not. I m=
ay just drop the reference as well since collection minimization and disclo=
sure minimization probably is self evident.=C2=A0

=
Best,=C2=A0

Nat

_______________________________________________

OAuth mailing list

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


-- 
Nat Sakimura


Chairman of the Board, OpenID Foundation




--001a1146995ea3de370548d3cd90--


From nobody Mon Feb 20 01:45:45 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD49128B38 for ; Mon, 20 Feb 2017 01:45:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.488
X-Spam-Level: 
X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nca2KVL8G0SR for ; Mon, 20 Feb 2017 01:45:43 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 A972D128AB0 for ; Mon, 20 Feb 2017 01:45:42 -0800 (PST)
Received: from [192.168.91.176] ([195.149.223.239]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Llmcq-1c6Pid2zNA-00ZOaa for ; Mon, 20 Feb 2017 10:45:39 +0100
To: "oauth@ietf.org" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: 
Date: Mon, 20 Feb 2017 10:45:37 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DJPOl7GBrK6hRIossnwnClSPpK7UVUuNN"
X-Provags-ID: V03:K0:ltrS6XHWY8zaBNpQIjq3uOkG+lh2kaTYFpFJyhtMhPok0EGgS/J +zg1h2TVFBwQkHLJfUGIjOStS0nkkbzEizLLm5Z3ECJ7i1g4y+ate5E2qAiuxTipbV7WQzm rZPm0StyCQl8addBkfDpmesg6+3kVXyzfHVVicGhfbhKT4OuwnKkM367zHnSZ8E4CbN5NgM A+bopuBjgO7N4whf1Xpbw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:wX5XXSRl5vo=:bTZ7gAKRhQA9+/MPeKagaB DKpGYoi1yruFGxI5mbgOFjpNL75Ho1GxOFiFrG+fU8wt0q1xgbkdd+mHAhr1Th9bQTnaRzJQv ZGy9LSW1GvtOLoKmAxgArK+hUU60sbwG2M0baOBUn9haoKoASlYgD2xG7egT5ZB9nop+LJ/iP 1bxbeqTtedJM25jVhRDJVh3225rZlAwgXyJsYuLgwzEsSmiql2HkvBe9pGNqT74AFkjUdyHfd w3RfmXdWo1sQsBGk8UGXs5VBR1s0PJKF2Bv3Kq/o7RJp5a17tCd03GDeNDmCQrCp+xk3LAzmH Lb5eiPUNKbmi48PVYwLUsP9pDdReAToOWRaQJR2V9KWJ77SzZNe9JGv2Ty2gDzMitybTYKXrC N4F2f7JAPVZ1QmnME1b59+0NKto0MiAqoXQLTvrvK86/IP+bWPgkuhT3LOtmWZuCREbK/ygvV JDMmXQGhWuEfFMAq/durQWtOpkCNctYKzyYFfnUCX1qFARETpJ1GSovQH/EB8P0Jdh0HasZBx HzQXASwRjt+oPlvC4JdmJWXhfE2pWe03135LOvgNDVm2pXez9r3BsHfroR88ddT0ykWijqd6w vPGgbOtuV47Z7r48c1MWoBXRyneQ0UV9dkIubDes/PMXNVGe/qTlM+/nOOjruMBPfzWvfOrPg E6WDyKQNVN6jxLhwET1JukLUDaw6l3bN70BonETJItLHfgPqgcQXFCJ1pLkxmNnY5BeOFRAOe nFsN1MDpCaGq0TZ/lnZS1vaGFMnPsZ+NcI9E5vKk627a/4f8j/AKW45gnpk=
Archived-At: 
Subject: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Feb 2017 09:45:44 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--DJPOl7GBrK6hRIossnwnClSPpK7UVUuNN
Content-Type: multipart/mixed; boundary="6mk3hbQOcAfdEhU3wuqx9MrQbkjEm6bX6";
 protected-headers="v1"
From: Hannes Tschofenig 
To: "oauth@ietf.org" 
Message-ID: 
Subject: Working Group Last Call on OAuth 2.0 Authorization Server Metadata

--6mk3hbQOcAfdEhU3wuqx9MrQbkjEm6bX6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

it was roughly a year ago when we issued a working group last call on
draft-ietf-oauth-discovery, see
https://www.ietf.org/mail-archive/web/oauth/current/msg15796.html. Lots
of feedback resulted in a significant restructuring of the document.

The authors of the draft now believe it is ready for a second WGLC and
hence we would like to start a 2-week review period.

Please provide your review comments no later than March 6th.

Here is the link to the document again:
https://tools.ietf.org/html/draft-ietf-oauth-discovery-05

Ciao
Hannes & Derek


--6mk3hbQOcAfdEhU3wuqx9MrQbkjEm6bX6--

--DJPOl7GBrK6hRIossnwnClSPpK7UVUuNN
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
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJYqrrCAAoJEGhJURNOOiAt1kcH/0njYJn6FUIAn9CT1PwHq+4u
WLH6G8XJaEVvafsaz/CBTZdmxRGDRUbhkrEeTTx83DyNZ6P+fq7UoTJ2gwnQQ40n
sjgNNwSUGi0e9S2dAVKEE8u37Jr81oF6tRKcigpDC+j38+9OoL9NgwPPwGzFMYeX
R9pgzMHQBxLGC1P6EK2LKIFaHHUYNDcNojaGR3XRzLnQZHjLfkQFLfdvz26bbpLW
RSdK1vmZjiu0OwT5bOKM7QLmBUHVDcJReHrNPxZQkUvUy/8RGvB6LcnAARjrW2uD
yNk6coNvHrlJ9q/QDRIB7lnXSDuH3/5IWxmkMCpsImZeFKydxhGshi36ivyETgs=
=1/LR
-----END PGP SIGNATURE-----

--DJPOl7GBrK6hRIossnwnClSPpK7UVUuNN--


From nobody Mon Feb 20 01:53:21 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6402612960C for ; Mon, 20 Feb 2017 01:53:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.488
X-Spam-Level: 
X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgBir2i00V_2 for ; Mon, 20 Feb 2017 01:53:18 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 A04D9128B38 for ; Mon, 20 Feb 2017 01:53:17 -0800 (PST)
Received: from [192.168.91.176] ([195.149.223.239]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MDyil-1cZuqK2nV9-00HLyy for ; Mon, 20 Feb 2017 10:53:15 +0100
To: "oauth@ietf.org" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <0f05922f-ac63-1585-9da1-d54ceda25623@gmx.net>
Date: Mon, 20 Feb 2017 10:53:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WgCUexji7OndbN7hoRbnqMLhDJLHMbfdu"
X-Provags-ID: V03:K0:qx3v6auHf00demkk1ZdWj3p6BxPO5LvdzA+7Q13UegWjX3NJEj3 Mx4dGhW5Dmg4WZnc6Y9d3Zr/BdLjmv0LNpzr/J9TtHQkpPykoaAQTGHQmXIhjPOXZiJxzxH xqAfkQvuQYN/lpK+xG3NDgvQmsLxuNZ8s1Wi3hQCUkWcY1qugolKN4YAwjajQC/+cQKgKEh Ufabg9wWPK/7/z+i07sTg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:+NEYzAfD6ag=:meK4Cjfhny6MsSk2Fusbmn nd9XW2Rm+ohckaxI2M+mXprrg0JIGDQeqh4bNTUcYKtv8WFcztfBpXZy5LjCGKgJ0cZG/zYpt GydK2lwB/Uo5iQxEue5UR5ydUBivY0NW6cRsGM6gGSNk/5ygJ0tQI7lU6YrRAB+Vb9kcuzNRZ v2RbYsx853PXwHBiV6SzrPM0kMDkbZS5APoDHTEjIFazQQQrplOjXCxwBLzULWr8AC3ixW1R8 nwKcZ112lfDqd2VCuGX4wPDVgAZPaDhdKSXGwSc9SOKYbq/gdxtFS/HsxlerbQbW4Du/o2h4h 8ywU6h6A5Nr96CEbutfurGxej90qul/06mkC/+l8iZOwZWiQKgTk6ENCeedFexFAmg42pS0Pd ypAgj/EHpFdFbDwwL2VL88yMtGq9HGqSmrKdTS6kNZqE2k8i7hGFFv4bAmoUgwH+j0ikU66SI 4c20aaeXx0S6lv+A60zZkjW4g3oPUV1mk7P06YXiuxZw453TRGuU+jMmpg18LMys+/RvgqJgG sbZe6vYXsucEOzp8xDCHLk7dewoEWX/XiBpcigJpSTHNniXEL861CDBmw1bF1hWme1ibFOOSw IDtj0PAxfiO80APMYFnvei912UH+tVp7jg2kvLRwdHvv1lR22vudZGSJMO+++zI4WNMNASjYF rusRwkzNTHLqmU34OQFhJgkrlR4LN3sKUU+77AQ6axtT5ha7oogm3yszTqlETOp1PGxxXx0jc 3kN3kCsyoxOwLlzKQ7fneiqc9Vls/VlK9wWMyx47jCNpMdjpvSU4aDFGf8E=
Archived-At: 
Subject: [OAUTH-WG] Pushing "OAuth 2.0 for Native Apps" to the IESG -- Short Working Group Last Call
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Feb 2017 09:53:19 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--WgCUexji7OndbN7hoRbnqMLhDJLHMbfdu
Content-Type: multipart/mixed; boundary="PtAPvvDeFrB41e2H11LN4fdk5aDA6Bjcq";
 protected-headers="v1"
From: Hannes Tschofenig 
To: "oauth@ietf.org" 
Message-ID: <0f05922f-ac63-1585-9da1-d54ceda25623@gmx.net>
Subject: Pushing "OAuth 2.0 for Native Apps" to the IESG -- Short Working
 Group Last Call

--PtAPvvDeFrB41e2H11LN4fdk5aDA6Bjcq
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

after the working group last call of the "OAuth 2.0 for Native Apps"
document July last year (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16534.html) I
had, as a shepherd, collected IPR confirmations (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16672.html) and
produced a shepherd writeup (see
https://www.ietf.org/mail-archive/web/oauth/current/msg16702.html).

Since version -03 and the current version -07 a fair amount of text has
been changed, see
https://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draft-iet=
f-oauth-native-apps-03.txt&url2=3Dhttps://tools.ietf.org/id/draft-ietf-oa=
uth-native-apps-07.txt

Although most of those changes are editorial and normative changes have
been discussed on the mailing list I believe it is fair to let the group
take a brief look at the final version.

For this reason we will issue a short, one week, working group last call
before pushing the document to the IESG.

So, please provide your comments to the list no later than February 27th.=


Here is the link to the document again:
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07

Ciao
Hannes & Derek


--PtAPvvDeFrB41e2H11LN4fdk5aDA6Bjcq--

--WgCUexji7OndbN7hoRbnqMLhDJLHMbfdu
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
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJYqryKAAoJEGhJURNOOiAtJDgH+wRCT/L+IJWAlGQ3oF6aE/nD
BLOSIZJR83OvR92RNcSnrSigkiuBrR7uTODUBxQcNGSJ0SHSAI8/GXpV3RBHg2OD
17iTU1JtDUAiqkdHTekFDa4znfVvUFUPjVPrrXGsXNFUfDczXNLdVg9ZJUbOroky
czYBnQ6B6pQBvj/g9ec1ygsoJR9S49S1bvDEgm+acjUK2RZuYTuavvBRIQPZSZEr
rrBtMc+ozes0GP4Q6gZ/hHHQ2R19VHkKI4elHbdEoinqThdh5kUWDvPGIYXxb6Fj
BR2arDABb4lAjJpF4r/gU8F0BxmY/wQwEb1RSjq4IG9Q3WEZi/Uf231tGgi99hU=
=84Mb
-----END PGP SIGNATURE-----

--WgCUexji7OndbN7hoRbnqMLhDJLHMbfdu--


From nobody Mon Feb 20 02:52:56 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F121299B0 for ; Mon, 20 Feb 2017 02:52:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.488
X-Spam-Level: 
X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd6D3PUybOAb for ; Mon, 20 Feb 2017 02:52:49 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 214F41299AA for ; Mon, 20 Feb 2017 02:52:48 -0800 (PST)
Received: from [192.168.91.176] ([195.149.223.239]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MRGTX-1cn9Pe3sB5-00UX8F; Mon, 20 Feb 2017 11:52:46 +0100
To: Denis , oauth@ietf.org
References:  <541A5105-B963-4FA4-94E4-D794A73B3358@ve7jtb.com>   <14c5b7d3-9faa-0e2f-1411-689ab13d4fad@manicode.com>  <0a8ab2ad-9f14-6915-464f-119a724422c7@free.fr>
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <1ebcff74-2c29-6b5c-a3cd-081cddbb3a2e@gmx.net>
Date: Mon, 20 Feb 2017 11:52:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <0a8ab2ad-9f14-6915-464f-119a724422c7@free.fr>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qPb66TK8jB4Efe1vw2fEgmMEuJuRIx4iC"
X-Provags-ID: V03:K0:8HWNyiPXc+JePJe6IvlG/L5B2hQE4qxTt5RcDYMhWyfzJCGfIjw hZIfJm15Vu7m9/KxlPeNAZKrHBrULsaafaJqQjBtiFmcuC6SZlHkJcgguMV5eReTdQoOwIQ yPy2mmJGFxmlh3nv8D4dp8A2uAgDy7yL4e72Z0j3JEsND6B0z/dZTH9doPF8l6lZMgm1KwY +BgF7gW77Lb4FVBlQUuBw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:JiUeumzYzIg=:8P1mo7ShB6GGv3ZgUj3epT lA8Ke/mvSnuooaPWaHwG2JtQF8lA4umkk7cTP+CYJoaIlXkmadNAkDOzGfZivqiEyz+eT5qKt lIPFrSZ0r/8GnXPh7fpvlxhb7dMumR4QIGtSGJFqz+a1y4TzSYIdhI8oMElZRWA0/23/+jWH7 9GqzRvYzF7+sOojggH/Y1bUAy6xBnO8inL66RmN27UHYt7OToRh9CEnTg5CkrX0mVYFNn1+Db QYjbuR2rBvwpaOwiYroKgGMUEACHT7hFI+smGawLnHBxcVjLF/dochDzf3iWdFyqgn1skoyuf AZYF8zXmEhFX7AQyQo9fDCYZ7TXmyD6hsOkx85HPaAdgjkdbwsZ9+hvF/sBT7bGS+B0YXcdDS Vt3JfJ+7xpe20J7j85C2b43+Lcm94YKWqBIVJDUCbHxRZPd5guLrTuU1GEs8jzgp2kFrJDMay rr8rAQ62nmSTzUA6J/7+XSy3dk4nsyVmbyYDufL8Jh5Q7XinTRYWgCEZs85i9INiXCl1HPgHJ 24OIim9lQN1cxD8tHtnaNlkQH3nyBe6Tn7OP2i9NfVqZZuh9XGQdDMlt8Mbzfaa6/pdx2urm2 TNlUCZVeZoM0Q61qijlJYPOzRHUI1Q4YMSeZ/X+8RXERZxy9lSQxCtZAKm0o/GtqDMXMxifcc hBMZviMvWfv97KlG2u8ipmzOaP2P2In3j/8c0JkI4mu1Mdc/9eH1yj+ymLxKpATl8B1H7YOCn n4PZp+y/DcOZm1RuqSek4uzLjcleXTNPs3FwylaDQI2XcpzYHrHcUfK4q/Y=
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Feb 2017 10:52:55 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--qPb66TK8jB4Efe1vw2fEgmMEuJuRIx4iC
Content-Type: multipart/mixed; boundary="oI3LoRJCJGFHAhfME2rFwDIo8lcs4sDtg";
 protected-headers="v1"
From: Hannes Tschofenig 
To: Denis , oauth@ietf.org
Message-ID: <1ebcff74-2c29-6b5c-a3cd-081cddbb3a2e@gmx.net>
Subject: Re: [OAUTH-WG] Call for adoption: OAuth Security Topics
References: 
 <541A5105-B963-4FA4-94E4-D794A73B3358@ve7jtb.com>
 
 
 <14c5b7d3-9faa-0e2f-1411-689ab13d4fad@manicode.com>
 
 <0a8ab2ad-9f14-6915-464f-119a724422c7@free.fr>
In-Reply-To: <0a8ab2ad-9f14-6915-464f-119a724422c7@free.fr>

--oI3LoRJCJGFHAhfME2rFwDIo8lcs4sDtg
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Denis,

thanks for your feedback regarding the scope.

The scope for this document is limited to the specifications we develop
in the IETF OAuth working group. OpenID Connect, UMA, or other
specifications need to be dealt with in other SDOs.

The document only represents a starting point for work and hence various
attacks, such as the ABC attack you mentioned, can be incorporated in
future versions of the document.

Ciao
Hannes

On 02/06/2017 01:30 PM, Denis wrote:
>=20
> The scope of this draft is unclear. The title states: "OAuth Security
> Topics".**
>=20
> I have some questions:
>=20
>   * Does this document intend to cover only the OAuth 2.0 delegation
>     protocol (since Justin said that OAuth 2.0 is a delegation protocol=
)
>     or OpenId Connect as well which is not limited to a delegation
>     protocol ?
>   * Should we discuss OpenID Connect issues and/or solutions in an IETF=

>     RFC ?
>=20
> If this document is going to be progressed, the threats should be
> clearly separated whether they relate to a delegation model or to
> a client-server access control model. This is not currently the case.
>=20
> If this document is going to be progressed, the ABC attack (in the
> context of an access control model) should be mentioned even if there e=
xits
> no way to counter it given the current implicit assumptions made in
> OAuth 2.0, in particular the use of software only implementations.
>=20
>=20
> Denis
>=20
>> A belated +1
>>
>>
>> On Sat, Feb 4, 2017, 9:08 AM Jim Manico > > wrote:
>>
>>     I'm just some random idiot am an not in this working group but the=

>>     work from
>>     https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topic=
s-00
>>     is one of the most up to date and useful OAuth security resources
>>     every published. I am thrilled to see more work put into it.
>>
>>     Aloha, Jim
>>
>>
>>     On 2/3/17 1:57 PM, William Denniss wrote:
>>>     I support the adoption of this document as a working group item.
>>>
>>>     On Thu, Feb 2, 2017 at 2:30 PM, Jim Willeke >>     > wrote:
>>>
>>>         +!=20
>>>         I agree this is needed.
>>>
>>>         --
>>>         -jim
>>>         Jim Willeke
>>>
>>>         On Thu, Feb 2, 2017 at 4:33 PM, John Bradley
>>>         > wrote:
>>>
>>>             I am in favour of adoption.
>>>             > On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig
>>>             >>             > wrote:
>>>             >
>>>             > Hi all,
>>>             >
>>>             > this is the call for adoption of the 'OAuth Security
>>>             Topics' document
>>>             > following the positive call for adoption at the last IE=
TF
>>>             > meeting in Seoul.
>>>             >
>>>             > Here is the document:
>>>             >
>>>             https://tools.ietf.org/html/draft-lodderstedt-oauth-secur=
ity-topics-00
>>>             >
>>>             > The intention with this document is to have a place to
>>>             collect
>>>             > discussions and conclusions around OAuth 2.0 security
>>>             and to reference
>>>             > the actual solution specifications.
>>>             >
>>>             > Please let us know by Feb 16th whether you accept /
>>>             object to the
>>>             > adoption of this document as a starting point for work
>>>             in the OAuth
>>>             > working group.
>>>             >
>>>             > Ciao
>>>             > Hannes & Derek
>>>             >
>>>             > _______________________________________________
>>>             > OAuth mailing list
>>>             > OAuth@ietf.org 
>>>             > https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>             _______________________________________________
>>>             OAuth mailing list
>>>             OAuth@ietf.org 
>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         OAuth@ietf.org 
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     OAuth@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>     --=20
>>     Jim Manico
>>     Manicode Security
>>     https://www.manicode.com
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>> --=20
>>
>> Nat Sakimura
>>
>> Chairman of the Board, OpenID Foundation
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20


--oI3LoRJCJGFHAhfME2rFwDIo8lcs4sDtg--

--qPb66TK8jB4Efe1vw2fEgmMEuJuRIx4iC
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
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJYqsp8AAoJEGhJURNOOiAtVykH/0kJEZIMmqRv4emb7uJ1GMZx
ShV+kseAbGebnnmitjYBRRTkVx1BMGmBWtbf3cMvUjSAowV44xKg/mG/UA4kD9pC
DyAB6GhwtbmgMAmI14NaktmEFtUMaJ/f3hVdUn+7gLQ5zmlyOIZtx6A4iEyf6U0j
8KB+K9wwtU4/aFM5W/Nq7qCFhgO8kCqJtYae1xwOHCTZG4qIPcMFZKi1iDYw5lFV
KvyITIEjWVquTQA2QhbuXAvAPA287nej7gf+HchlLZFN43vLeIf9GljT3ehAseBt
4abvXQqvQw1kyzsHr33jT4X3vOOAemFhWzgPqWmfw6Biy6Si3zTkN03QQ1V5Png=
=euv7
-----END PGP SIGNATURE-----

--qPb66TK8jB4Efe1vw2fEgmMEuJuRIx4iC--


From nobody Mon Feb 20 03:02:49 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0549212945D for ; Mon, 20 Feb 2017 03:02:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.488
X-Spam-Level: 
X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJJg8YolT9RE for ; Mon, 20 Feb 2017 03:02:46 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 50D56128B38 for ; Mon, 20 Feb 2017 03:02:46 -0800 (PST)
Received: from [192.168.91.176] ([195.149.223.239]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LyVcA-1cKA9l3CvG-015uHs for ; Mon, 20 Feb 2017 12:02:43 +0100
To: "oauth@ietf.org" 
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <7d639f9c-aecf-5b9b-be56-e16fd5437551@gmx.net>
Date: Mon, 20 Feb 2017 12:02:42 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qouKkgSrxmWe50Wmm2aiA4c5vKQ8sSQxp"
X-Provags-ID: V03:K0:iOdHxe1yIEm2nfG7xK2+JSWuDUBbON41L1zAfGQnqDcrswHeN1D 7NdlayJ9Cz4cS//lkix4DxemsWc/g1/YJahqRhuGPOqb+bWan3T3hwmEmdHYMYK0wy37Iwm 4Ob5yT/UO9XgDdeofv80TV8UXDPw377PfL8C7Kqhp8y5N7JRYx1GjQR+rNF9yoOFOXmTNtV pzIoicQ09kL/+4d3mUM/Q==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ysJX7lWEZ6Q=:W3Mlswn6dqvOyiuzYAU4cA 8bkIwHkjiDJtvXbYH2hkT6r/BxijZy15+67v8jBozUsV6GwMBXzUJZVmrRY5CZQiCmLaTqFwk Vu+pPFfnIEgxjqLa9Q0zRn09F/WANFJ9DK/EuKEiHTB301JL5erTiS6y0GuEkXyX7kPkzaxb1 1bjDRrwNZPGlPDeh+woTJotip2DKUWmtXs2ojkl9kVpeDTv8bEwzpItp3i2l25lLI1og4KaOp sY7ubvnWzOy6aeEiOOL7rVBTd9v3Zgapr7/gbadXZC4Ysker2HIAK8wCfEDCtcLXQ1fcIP7bk k1pAlBQJ6PN46pkTBo5quFs4gbkbN5Y2Rh2nnkHKq6ilv+JcdzhjKNoxH2b8zB2oWj71588mc Vjv65VXXSS/6+iDXa7jVzvzmf9M3mw8NuQDrJ4HPXovcs97WF0YAbIPHwQpCleObD4Q9/JPqS LAiiWGk+LJiZwQQ4Q3VvPMe/1sPjcfg2jeyZngYmuIq6wnX5nWNFTWGZrih8Qf/F8VJ0JEGLR jh2pFNxPRQcWgc0YQdMAYp04mrxGdQFDBFm0gERw+mWft2A5e1heWU57czD8NWBiVUeBNIpJL CzHK1bR2sRQqabHlVizs9G+ObiipSvRVpzVTTfWtRs/idlt0hbopEJXgwk+TKSZsYqFiWxk3T MLObTENb2ZIq5+n3Oo+74JsLBrlcPjK3p3ME/RK7AiFOV+7I84HeWI9vZqORSd86yt6Ll46yd NSr6pfFbzANu45ijE/+K6WEEz9xZAOWuARkhRnoWBuOsepszC5Mstkbd6oI=
Archived-At: 
Subject: [OAUTH-WG] Conclusion of 'OAuth Security Topics' Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Feb 2017 11:02:48 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--qouKkgSrxmWe50Wmm2aiA4c5vKQ8sSQxp
Content-Type: multipart/mixed; boundary="kq6ocxIBPR8w7VSbaqjiR04cjvAX8HPId";
 protected-headers="v1"
From: Hannes Tschofenig 
To: "oauth@ietf.org" 
Message-ID: <7d639f9c-aecf-5b9b-be56-e16fd5437551@gmx.net>
Subject: Conclusion of 'OAuth Security Topics' Call for Adoption

--kq6ocxIBPR8w7VSbaqjiR04cjvAX8HPId
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi all,

earlier this month we issued a call for adoption of the OAuth security
topics draft, see draft-lodderstedt-oauth-security-topics-00, and the
response was quite positive on the list (as well as during the last f2f
meeting).

For this reason, we ask the authors to submit a WG version of the
document and to discuss new content for the document in preparation for
the next meeting.

Note that the intention of the document is to discuss security topics as
they relate to the work in the OAuth working group. As this initial
document already does, it describes a problem statement and outlines
various ways to mitigate the problems. I expect the working group to
decide which solution approach is most appropriate and to detail it (at
a specification level) in a separate document (some of those documents
already exist in the working group). This should help us make decisions
that are not just point solutions for specific problems but rather
consider the big picture.

Ciao
Hannes & Derek


--kq6ocxIBPR8w7VSbaqjiR04cjvAX8HPId--

--qouKkgSrxmWe50Wmm2aiA4c5vKQ8sSQxp
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
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJYqszSAAoJEGhJURNOOiAtc4AH/37tFx78u6u2qmCou0SzjPh1
Ilo/WshFo9LC58RwStlrEhxZJCJEt/3Awdj3dLXVT73aXiZLkPwa7aOMSFIVKX5n
sOa/CEFbuHUCkpMIaZyTV6x4M4RtOzG8fjSpwLGODQj0l09a1voS6l0cekgqTXMT
AhIAMGt1/5o5GHPaBifbNXMaYyrkXIcmubrMVyAjJmUaTEFc2klMQ2k6iBKWXXFy
JzxT7oXLVZiAyTV3aHmD6Lhst9KQoHSpdaBzl3jquzNk8m06UeQFYZ5Gs2SCoM4Q
UTXBDwvrniDZ7DGNJstqlEG+VKLU3ukSx0s0AONIT1kbp6yyNSWFDjZVXdRFwkE=
=Zhh/
-----END PGP SIGNATURE-----

--qouKkgSrxmWe50Wmm2aiA4c5vKQ8sSQxp--


From nobody Mon Feb 20 08:33:10 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DA6129559 for ; Mon, 20 Feb 2017 08:33:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Level: 
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdvILXNIUZnf for ; Mon, 20 Feb 2017 08:33:06 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0111.outbound.protection.outlook.com [104.47.34.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF661295F7 for ; Mon, 20 Feb 2017 08:33:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tecI3Xfs13+whp7iwkrb6MUUW2vO6uzatCqE8lMkNPo=; b=O6vxwlNqLtlvRYqsbxjCI24m1MZatWyisA7UWRGzF8xA/Q9f9KwuiD9KaXB5ZluIucz9KbVBm/Fl2Fo8Y+eAkmO+q9EfV6Dd2xpVINgZt09hJwxXqBnzooLZQAYAV33tSFGCEbzSdNLx9VptOUB8tcVn0zepHC4lzEsBIpp4J0Q=
Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0501.namprd21.prod.outlook.com (10.172.122.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.2; Mon, 20 Feb 2017 16:33:04 +0000
Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.0933.011; Mon, 20 Feb 2017 16:33:04 +0000
From: Mike Jones 
To: Hannes Tschofenig , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata
Thread-Index: AQHSi14fZ7sdla/+90i7+viIHkFvlqFyFnRw
Date: Mon, 20 Feb 2017 16:33:04 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.83.32]
x-ms-office365-filtering-correlation-id: ec9449a1-3d22-401e-033d-08d459ae24d6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0501; 
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0501; 7:9l+WgAQUKQlSdEvkZMzVj6/n2UZ29jKwJszt7GAvnnw0s72iUkEKkesOWSotohcjBApC6IIr8Hs7/noOT/i3MNXOLs8fw5ODoAKF3HLgvbzATCuPPNjYpH0/fRJyUlKtT1A7/WCBdCmS27ZFuFt7E0MjZadCyrGjsjbTxCeFCdobGnTKjmF5+V5XclLHZ23Xra3gKTNjWYg6SpxXjQraexfmnZBYLX7H1qpDbHWI2RxNmeUuWePGi1WPnX5ea39VXzVb/Q0hbUK7vGoHVdIdMM3Wg2ok+Az0iZXHs3jOMNIjY0i+RvsYFVYR7fcLMm3MeWR6HlzlcagXp7coWUphfU5sP3VzwCWH/OTlkiVNoBs=
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6042181)(6072148); SRVR:CY4PR21MB0501; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0501; 
x-forefront-prvs: 02243C58C6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(53754006)(199003)(377454003)(189002)(13464003)(106116001)(86612001)(106356001)(99286003)(81166006)(8990500004)(68736007)(101416001)(6306002)(54356999)(50986999)(76176999)(189998001)(81156014)(55016002)(9686003)(97736004)(2906002)(122556002)(25786008)(3846002)(102836003)(6116002)(33656002)(3660700001)(7736002)(8936002)(105586002)(3280700002)(86362001)(10090500001)(66066001)(6506006)(10290500002)(74316002)(6436002)(305945005)(5005710100001)(229853002)(77096006)(2950100002)(92566002)(7696004)(53546006)(6246003)(38730400002)(2501003)(53936002)(2900100001)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0501; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2017 16:33:04.1397 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0501
Archived-At: 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Feb 2017 16:33:09 -0000

UGVyIHdvcmtpbmcgZ3JvdXAgZmVlZGJhY2ssIHRoZSBkb2N1bWVudCBub3cgcmVmbGVjdHMgdGhl
IHNpbmd1bGFyIG1pc3Npb24gb2YgZG9jdW1lbnRpbmcgT0F1dGggQXV0aG9yaXphdGlvbiBTZXJ2
ZXIgTWV0YWRhdGEgYXMgaXQgaXMgYWN0dWFsbHkgdXNlZCBpbiBwcmFjdGljZS4gIEkgYmVsaWV2
ZSB0aGF0IHRoZSBkb2N1bWVudCB0b2RheSBhY2NvbXBsaXNoZXMgdGhpcyBtaXNzaW9uIGFuZCBp
cyByZWFkeSBmb3IgcHVibGljYXRpb24uDQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmdd
IE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAy
MCwgMjAxNyAxOjQ2IEFNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtPQVVUSC1XR10g
V29ya2luZyBHcm91cCBMYXN0IENhbGwgb24gT0F1dGggMi4wIEF1dGhvcml6YXRpb24gU2VydmVy
IE1ldGFkYXRhDQoNCkhpIGFsbCwNCg0KaXQgd2FzIHJvdWdobHkgYSB5ZWFyIGFnbyB3aGVuIHdl
IGlzc3VlZCBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9uIGRyYWZ0LWlldGYtb2F1dGgtZGlz
Y292ZXJ5LCBzZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9j
dXJyZW50L21zZzE1Nzk2Lmh0bWwuIExvdHMgb2YgZmVlZGJhY2sgcmVzdWx0ZWQgaW4gYSBzaWdu
aWZpY2FudCByZXN0cnVjdHVyaW5nIG9mIHRoZSBkb2N1bWVudC4NCg0KVGhlIGF1dGhvcnMgb2Yg
dGhlIGRyYWZ0IG5vdyBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBhIHNlY29uZCBXR0xDIGFuZCBo
ZW5jZSB3ZSB3b3VsZCBsaWtlIHRvIHN0YXJ0IGEgMi13ZWVrIHJldmlldyBwZXJpb2QuDQoNClBs
ZWFzZSBwcm92aWRlIHlvdXIgcmV2aWV3IGNvbW1lbnRzIG5vIGxhdGVyIHRoYW4gTWFyY2ggNnRo
Lg0KDQpIZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBkb2N1bWVudCBhZ2FpbjoNCmh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRpc2NvdmVyeS0wNQ0KDQpDaWFvDQpI
YW5uZXMgJiBEZXJlaw0KDQo=


From nobody Mon Feb 20 16:59:32 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA4812955C for ; Mon, 20 Feb 2017 16:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlgCXPkCSQrT for ; Mon, 20 Feb 2017 16:59:29 -0800 (PST)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 CD797120725 for ; Mon, 20 Feb 2017 16:59:28 -0800 (PST)
Received: by mail-qt0-x22b.google.com with SMTP id k15so100048120qtg.3 for ; Mon, 20 Feb 2017 16:59:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TTXYTxuBE9rEtl8/gjjCzFwt5USE09EbVHsQlGLN9uk=; b=CHaXH1jIKSCeib/Sv0SVJErTCMjkdsDha1TstwAHKnRx7MnlhH+3NA+7qbgheMT8Sw jcEcYyuknuYFigE2me9JSu25fqvYhcj0SOZQompZ7VaEG2P9ijOku/TpgdBbEVo0L96K DrENsFu6r7A0ldhhYSYkM48byMJSOstm8xYfn/vju4u4ogydiYMBGcuIW60fSyXg3XGP cL6OB2QLapnqzH8sP5e3MguTpnPONexzib5EtUQh4pTY4fFC0TDibGRmfqvSBRCHeyjA TCD+3AZ3d3FQj2vJ9Q2Kci2qffFR0lVg/unScmSx26mg7vNlCWybsmi7GBH4eVuEPSlY /odw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TTXYTxuBE9rEtl8/gjjCzFwt5USE09EbVHsQlGLN9uk=; b=PYRSvgjshrQwDkyFjvg0AtA/fz3wrwYSc1/4zXjPtRPYmxnfcX1NALUjODkzdDlKkl pnh5rz7ueeXpVF5EDcGpcLTV5bUUvDe0z3c6kKSuMNMxmEV8DXpAEoG2E6pIehpLXwCp 1CgG2T+dYoZGrnaF5Q7PZBIKBVVhkLmaSLBVEIi6YWVceB33mKfhxF/Lx2oUyGjQF8hS Rf2eYbBJ0INf+VEiL6yUZfyLvUJiwl1fHUK5edDRT8TRjWoAop5/1ZrH1KetJaJO2Uz9 1+h2jQzyftE/YwzfGgKBGlP7cpZNTITFVkez4QLV65mLMAr+lW7gtGzUMjQMSZ16zCci JUDQ==
X-Gm-Message-State: AMke39mwwzCXKU1GyMHRzaU0Ag8Pjz1/3/h72X2RP+yS9BokNDJLMg2LAesUDDR0hy4he+qlruTfc8OMjVBEFEMo
X-Received: by 10.237.36.85 with SMTP id s21mr23664558qtc.80.1487638767783; Mon, 20 Feb 2017 16:59:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.16.207 with HTTP; Mon, 20 Feb 2017 16:59:07 -0800 (PST)
In-Reply-To: 
References: 
From: William Denniss 
Date: Mon, 20 Feb 2017 16:59:07 -0800
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a113bfc704f34d80548ffe4bb
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 00:59:30 -0000

--001a113bfc704f34d80548ffe4bb
Content-Type: text/plain; charset=UTF-8

I have reviewed version 05. Two minor comments regarding Section 2.1:

1. Should we clarify that alg:none isn't supported for the signed_metadata
JWT (since it would be contradictory)?

2. Re: "metadata values conveyed in the signed metadata MUST take
precedence over those conveyed using plain JSON elements."  Does this imply
that *all* values in the plain JSON elements should be ignored when the
signed_metadata is being used (not just ones present in the JWT)? If not,
should it?


Overall, I strongly support the publishing of this document as an RFC for
the following reasons:

Having "machine readable" configuration metadata published by authorization
servers is a useful concept. The Google authorization server (like many
others) publishes metadata compliant with this specification, and the
AppAuth series of client libraries are capable of consuming it.

Without this standardized machine-readable metadata, developers must read
documentation to extract the relevant information, and configure clients
manually. This is cumbersome, error prone, and may get out of date.

This specification can also help prevent one category of "mix up" attack in
systems which allow self-registration of OAuth endpoints for connected
services. Rather than the developer supplying both the authorization and
token endpoints themselves (which may enable them to specify a malicious
token endpoint), such a system can use the token endpoint specified in the
authorization server's metadata, thus preventing this category of attack
(and simplifying the registration process to boot).


On Mon, Feb 20, 2017 at 1:45 AM, Hannes Tschofenig <
hannes.tschofenig@gmx.net> wrote:

> Hi all,
>
> it was roughly a year ago when we issued a working group last call on
> draft-ietf-oauth-discovery, see
> https://www.ietf.org/mail-archive/web/oauth/current/msg15796.html. Lots
> of feedback resulted in a significant restructuring of the document.
>
> The authors of the draft now believe it is ready for a second WGLC and
> hence we would like to start a 2-week review period.
>
> Please provide your review comments no later than March 6th.
>
> Here is the link to the document again:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-05
>
> Ciao
> Hannes & Derek
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a113bfc704f34d80548ffe4bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I have reviewed version 05. Two minor comments regarding S=
ection=C2=A02.1:

1. Should we clarify that alg:none isn't =
supported for the signed_metadata JWT (since it would be contradictory)?

2. Re: "metadata values conveyed in the signed metadata MUST take precede=
nce over those conveyed using plain JSON elements." =C2=A0Does this imply that *all* values in the pl=
ain JSON elements should be ignored when the signed_metadata is being used =
(not just ones present in the JWT)? If not, should it?

<=
/div>

Overall, I strongly support the publishing of this=
 document as an RFC for the following reasons:

Hav=
ing "machine readable" configuration metadata published by author=
ization servers is a useful concept. The Google authorization server (like =
many others) publishes metadata compliant with this specification, and the =
AppAuth series of client libraries are capable of consuming it.
<=
br>
Without this standardized machine-readable metadata, develope=
rs must read documentation to extract the relevant information, and configu=
re clients manually. This is cumbersome, error prone, and may get out of da=
te.

This specification can also help prevent one c=
ategory of "mix up" attack in systems which allow self-registrati=
on of OAuth endpoints for connected services. Rather than the developer sup=
plying both the authorization and token endpoints themselves (which may ena=
ble them to specify a malicious token endpoint), such a system can use the =
token endpoint specified in the authorization server's metadata, thus p=
reventing this category of attack (and simplifying the registration process=
 to boot).


On Mon, Feb 20, 2017 at 1:45 AM, Hann=
es Tschofenig <hannes.tschofenig@gmx.net> wrote:
=

Hi all,



it was roughly a year ago when we issued a working group last call on

draft-ietf-oauth-discovery, see

https://www.ietf.org/mail-arch=
ive/web/oauth/current/msg15796.html. Lots

of feedback resulted in a significant restructuring of the document.



The authors of the draft now believe it is ready for a second WGLC and

hence we would like to start a 2-week review period.



Please provide your review comments no later than March 6th.



Here is the link to the document again:

https://tools.ietf.org/html/draft-ie=
tf-oauth-discovery-05



Ciao

Hannes & Derek




_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





--001a113bfc704f34d80548ffe4bb--


From nobody Mon Feb 20 22:04:43 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35FD129B11 for ; Mon, 20 Feb 2017 22:04:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FiPNhcNjoth for ; Mon, 20 Feb 2017 22:04:41 -0800 (PST)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278981296A1 for ; Mon, 20 Feb 2017 21:57:20 -0800 (PST)
Received: by mail-oi0-x234.google.com with SMTP id 2so23738652oif.0 for ; Mon, 20 Feb 2017 21:57:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=37tJguPbQ5vfldBAGmMtvoLNocXAqnIDLs9HGEAdAgw=; b=ZAROpUwL7GlgqYX4eTRxT4vk47V2CL8kDmF0axV+fE6dhSvOtdtfEKXBbFV6DhQlY2 Ukg+A64N8vjddDrgGjZPS6Em7higzb4B3Axsudr59EN77Gmx7a21asEHBacjm4fyAcLf Mrw675kAkqO0f84SZXX0TXwJZ9uQciySuerzjcJ1onmdey63DtnrbUbkNdNqWdOFV9h5 yYYJOgGher5gvraSKI4pw833Un5X8QgvEIeNBKinsv0+Uz+Kq5B0/Rd1f/r0QAWBfaaR gfvZEVgKeLQTYwO8qSzdhUYcZhM1WoIji4m04VRoEcFnvoRxJA9W59iasbONk+hfka2M 8rFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=37tJguPbQ5vfldBAGmMtvoLNocXAqnIDLs9HGEAdAgw=; b=Sbz7HEOrr3YPD4kCBVKcYvn0irWq3glePuKJNFkzftGNtrhvepmybRC76AXLVezqRP 1+yRX/2Wu3cFaWP+xRclNwIYWkBPX4qCqO4XdeL7S5NhF1Ok8SYCWE+Iuga49qXfn/wZ zhfsZNvGVTXKXCg2Lj0V4k16Vos3/lVH3SYKQ1ltejxnPaZkVYR7PneApqlTaZmnUiDg WtZOyPm7bg+MRz4dmoNQdn2UD2o3FQPVrGNVqre+DcWARTLJrpD7r4zIBNkkybPGk8A9 olrXCQDHoPB59162jpe0RgxRoSRfzNfCnxOTMCzEF/y7oFo665k4MIbmu/JwPbTN1RFr Decw==
X-Gm-Message-State: AMke39mes/sbWfnTLo2Mm29dkZGuvbHBMgiRkjaMVeUesRT9qJ6XmNtx0HOStIMDnxJuEz0i0wm5w/ySGKhanw==
X-Received: by 10.202.7.68 with SMTP id 65mr7694175oih.34.1487656639904; Mon, 20 Feb 2017 21:57:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.8.74 with HTTP; Mon, 20 Feb 2017 21:57:19 -0800 (PST)
From: Samuel Erdtman 
Date: Tue, 21 Feb 2017 06:57:19 +0100
Message-ID: 
To: William Denniss , John Bradley 
Content-Type: multipart/alternative; boundary=94eb2c13f24891d0e70549040ddb
Archived-At: 
Cc: Hannes Tschofenig , "" 
Subject: [OAUTH-WG] review draft-ietf-oauth-native-apps-07
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 06:04:42 -0000

--94eb2c13f24891d0e70549040ddb
Content-Type: text/plain; charset=UTF-8

Hi,

I just had a question on best practice. In this document a large part of
the normative text is located under Security Considerations.

I had previously seen Security Considerations as things to think about when
implementing not so much as MUSTs and MUST NOTs.

I think it is okay to have it this way but it surprised me a bit and wanted
to ask if there is any best practice for the Security Considerations
section saying what type of information it should include.

Best Regards
Samuel Erdtman

--94eb2c13f24891d0e70549040ddb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I just had a question on b=
est practice. In this document a large part of the normative text is locate=
d under Security Considerations.

I had previously seen Securit=
y Considerations as things to think about when implementing not so much as =
MUSTs and MUST NOTs.

I think it is okay to have it this way bu=
t it surprised me a bit and wanted to ask if there is any best practice for=
 the Security Considerations section saying what type of information it sho=
uld include.

Best Regards
Samuel Erdtm=
an


--94eb2c13f24891d0e70549040ddb--


From nobody Mon Feb 20 22:44:52 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16794129873 for ; Mon, 20 Feb 2017 22:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAdTV8pLcZXU for ; Mon, 20 Feb 2017 22:44:49 -0800 (PST)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 31477129861 for ; Mon, 20 Feb 2017 22:44:49 -0800 (PST)
Received: by mail-qk0-x232.google.com with SMTP id u188so38431578qkc.2 for ; Mon, 20 Feb 2017 22:44:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nhHATXyJP317MVkMOlrxMwJPYriYIrbD82vR6ALs05Q=; b=KmeHsvmCHda//6EMkAr22q1sGuI//WI1AtMdoL/49bbk0/AHdabLbJUFJDSHZXb38D i2sYRGgCikzxtT0+JCgwxPdqDN+Bfzq9Xj1VILrLmlgcEudAPH0bQrFgY7xM5kFdjCN+ +fMJZgURPUwudCMOC8Zyw1yGt7drzjYFrZ4XG+Q0tnteVIM8DVf7MQc7ucQ3DWthf/ns 9+3m0yL5SF+0guShSn/NeTGwhCcIAegD2F21+FQKrLgeVu4mSnt/owpcxJ/D0dk/3W76 RRs35Il2YvdpUclrYtfNmwoRNv2s6igl+iSllpafMvEhyyD6sk3nwLkTu3Wa0A8U5gWb 4sMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nhHATXyJP317MVkMOlrxMwJPYriYIrbD82vR6ALs05Q=; b=IOYEmekXP2pHSTMOSmER7zoAPunogLhs4eJN0YLhui4MDSWtV0HColYmDC+MB6C5rS LY+VwThVR9Uezd9FoM5mXFk0A0V57jRW7ZJXLmI7XCrcrTq4ZxVXamYFInqGUAWHvF12 nf+pLGK4HfZZt/RNNKhdxBOYOf+uCMXsv3A4tUjQ3dxPJWWZ+ml4G7pcgGz2jkbKDZWl 8K+nz/N3u0+Lf9n/oDJqR5K7x9u5Spk7wXN86XpvfxH2D0Hmd90Rnb/OE8Kl3Yt9GYzI 7Gh7au0947aIMMifbfMjqSGLOkhMyOQj0JczqbA6dDgJYVW53A51KasnsP2ARqsh75/J yb5g==
X-Gm-Message-State: AMke39mSSEHGbjnieM3Sr+ADglaeVTugCLzYypSXjTl9lNjX1ZimntvnfNTITngfNQuVCRHwc0wie1XGy0nS0FC2
X-Received: by 10.55.139.70 with SMTP id n67mr21402795qkd.286.1487659487903; Mon, 20 Feb 2017 22:44:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.16.207 with HTTP; Mon, 20 Feb 2017 22:44:27 -0800 (PST)
In-Reply-To: 
References: 
From: William Denniss 
Date: Mon, 20 Feb 2017 22:44:27 -0800
Message-ID: 
To: Samuel Erdtman 
Content-Type: multipart/alternative; boundary=94eb2c08849053238d054904b780
Archived-At: 
Cc: Hannes Tschofenig , "" 
Subject: Re: [OAUTH-WG] review draft-ietf-oauth-native-apps-07
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 06:44:51 -0000

--94eb2c08849053238d054904b780
Content-Type: text/plain; charset=UTF-8

I do think it's normal to have normative text in the Security
Considerations.  RFC6749 has a lengthy Security Considerations section
 with a lot of normative
text.

Think of it this way: Sections 4 to 7 describe how to use native app URI
schemes to perform OAuth flows from the app to browser and back. If you
only read those sections, you could have a functioning (but potentially
insecure) OAuth flow in a native app. The security section adds some
security requirements and clarifications for implementing Sections 4-7,
like using PKCE, and more.

Reviewing sub-section by sub-section:

8.1 Definitely belongs here, as the the whole BCP is about native-app URI
schemes, whereas doing OAuth in a WebView doesn't need those (as the client
can just pluck out the code from any redirect URI)
8.2 Requires that servers who want to follow the native apps BCP support
PKCE, and recommends that they reject requests from clients who don't.
This *could* be in the main doc, but since PKCE is an existing thing, and
is purely additive from a security perspective, I think this reference
works fine. Originally I talked about PKCE more in the doc body, but some
reviewers thought it was then a little duplicative of the PKCE doc itself.
8.3 This reads like classic security considerations to me, clarifying some
details of 7.3
8.4 Part of this reads a little new-ish, regarding distinguishing native
clients from web ones. But on review, I think could just be re-worded to
reference RFC6749 Section 2.1.
8.5 This one belongs where it is since the body of the BCP is talking about
the code flow.
8.6 Totally belongs.
8.7 to 8.11 belong IMO, they are security clarifications of long-standing
topics.

My methodology when reviewing this was: is the text introducing a new topic
directly related to native apps or sections 4-7, or does it discuss an old
security topic in the context of native apps, or add security related
discussions of the content in 4-7. Of all those, I really only see a bit of
new topic related to native apps in 8.4, and in actual fact it that
sub-section should probably be reworded since RFC6749 already establishes
the public client type, which native apps are and a reference would be more
appropriate (which would reduce it to just clarifying an old topic).

What do you think of this analysis? Do you have any specific sections or
text you feel are better suited in the document body?  I will take an
action item to revise section 8.4.

On Mon, Feb 20, 2017 at 9:57 PM, Samuel Erdtman  wrote:

> Hi,
>
> I just had a question on best practice. In this document a large part of
> the normative text is located under Security Considerations.
>
> I had previously seen Security Considerations as things to think about
> when implementing not so much as MUSTs and MUST NOTs.
>
> I think it is okay to have it this way but it surprised me a bit and
> wanted to ask if there is any best practice for the Security Considerations
> section saying what type of information it should include.
>
> Best Regards
> Samuel Erdtman
>

--94eb2c08849053238d054904b780
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I do think it's normal to have normative text in the S=
ecurity Considerations.=C2=A0 RFC6749 has a lengthy Security Considerations section wit=
h a lot of normative text.

Think of it this way: Section=
s 4 to 7 describe how to use native app URI schemes to perform OAuth flows =
from the app to browser and back. If you only read those sections, you coul=
d have a functioning (but potentially insecure) OAuth flow in a native app.=
 The security section adds some security requirements and clarifications fo=
r implementing Sections 4-7, like using PKCE, and more.

Reviewing sub-section by sub-section:

8.1 De=
finitely belongs here, as the the whole BCP is about native-app URI schemes=
, whereas doing OAuth in a WebView doesn't need those (as the client ca=
n just pluck out the code from any redirect URI)
8.2 Requires tha=
t servers who want to follow the native apps BCP support PKCE, and recommen=
ds that they reject requests from clients who don't.=C2=A0 This *could*=
 be in the main doc, but since PKCE is an existing thing, and is purely add=
itive from a security perspective, I think this reference works fine. Origi=
nally I talked about PKCE more in the doc body, but some reviewers thought =
it was then a little duplicative of the PKCE doc itself.
8.3 This=
 reads like classic security considerations to me, clarifying some details =
of 7.3
8.4 Part of this reads a little new-ish, regarding disting=
uishing native clients from web ones. But on review, I think could just be =
re-worded to reference RFC6749 Section 2.1.
8.5 This one belongs =
where it is since the body of the BCP is talking about the code flow.
=

8.6 Totally belongs.
8.7 to 8.11 belong IMO, they are securi=
ty clarifications of long-standing topics.=C2=A0

M=
y methodology when reviewing this was: is the text introducing a new topic =
directly related to native apps or sections 4-7, or does it discuss an old =
security topic in the context of native apps, or add security related discu=
ssions of the content in 4-7. Of all those, I really only see a bit of new =
topic related to native apps in 8.4, and in actual fact it that sub-section=
 should probably be reworded since RFC6749 already establishes the public c=
lient type, which native apps are and a reference would be more appropriate=
 (which would reduce it to just clarifying an old topic).

What do you think of this analysis? Do you have any specific sectio=
ns or text you feel are better suited in the document body?=C2=A0 I will ta=
ke an action item to revise section 8.4.

On Mon, Feb 20, 2017 at 9:57 PM, Samuel =
Erdtman <samuel@erdtman.se> wrote:
Hi,

I just had a qu=
estion on best practice. In this document a large part of the normative tex=
t is located under Security Considerations.

I had previously s=
een Security Considerations as things to think about when implementing not =
so much as MUSTs and MUST NOTs.

I think it is okay to have it =
this way but it surprised me a bit and wanted to ask if there is any best p=
ractice for the Security Considerations section saying what type of informa=
tion it should include.

Best Regards
Samuel Erdtman





--94eb2c08849053238d054904b780--


From nobody Tue Feb 21 00:36:51 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CB3128B37 for ; Tue, 21 Feb 2017 00:36:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_RyPxK3gFZ6 for ; Tue, 21 Feb 2017 00:36:48 -0800 (PST)
Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE70129529 for ; Tue, 21 Feb 2017 00:36:47 -0800 (PST)
Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs02.index.or.jp (Postfix) with ESMTP id A2AA1196868 for ; Tue, 21 Feb 2017 17:36:46 +0900 (JST)
Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 27B5E4E0046 for ; Tue, 21 Feb 2017 17:36:46 +0900 (JST)
Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id v1L8akQD024901 for ; Tue, 21 Feb 2017 17:36:46 +0900
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea05.index.or.jp with ESMTP id v1L8ajn4024899 for ; Tue, 21 Feb 2017 17:36:45 +0900
Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v1L8ajNE013185; Tue, 21 Feb 2017 17:36:45 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id v1L8ajBh013161; Tue, 21 Feb 2017 17:36:45 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf15.index.or.jp ([172.100.25.24]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v1L8ajaB013077 for ; Tue, 21 Feb 2017 17:36:45 +0900
From: "Nat Sakimura" 
To: 
Date: Tue, 21 Feb 2017 17:36:50 +0900
Message-ID: <01f901d28c1d$a56fbf30$f04f3d90$@nri.co.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FA_01D28C69.15585190"
X-Mailer: Microsoft Outlook 15.0
X-MailAdviser: 20141126
Thread-Index: AdKMHMoCY8Q6YeBrS2+BVz8RcCZ/fQ==
Content-Language: ja
Archived-At: 
Subject: [OAUTH-WG] draft-ietf-oauth-token-binding-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 08:36:50 -0000

This is a multipart message in MIME format.

------=_NextPart_000_01FA_01D28C69.15585190
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi OAuthers: 

 

I was reading draft-ietf-oauth-token-binding-01 this afternoon and thought
that examples for each subsection of 2 and 3 would be helpful. 

 

Is it possible/sensible to add them? 

 

Best, 

 

Nat

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

 


------=_NextPart_000_01FA_01D28C69.15585190
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi =
OAuthers: 
 
I was =
reading draft-ietf-oauth-token-binding-01 this afternoon and thought =
that examples for each subsection of 2 and 3 would be helpful. =

 
Is it =
possible/sensible to add them? 
 
Best, =

 
Nat
--
PLEASE READ :This =
e-mail is confidential and intended for the
named =
recipient only. If you are not an intended =
recipient,
please notify the =
sender  and delete this e-mail.
 

------=_NextPart_000_01FA_01D28C69.15585190--


From nobody Tue Feb 21 00:50:13 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C929129529 for ; Tue, 21 Feb 2017 00:50:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbOe2G-yW0h2 for ; Tue, 21 Feb 2017 00:50:09 -0800 (PST)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (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 72A08129643 for ; Tue, 21 Feb 2017 00:50:09 -0800 (PST)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 3A5B8780375 for ; Tue, 21 Feb 2017 09:50:07 +0100 (CET)
To: oauth@ietf.org
References:  
From: Denis 
Message-ID: <304c520f-e531-2ac8-f93f-b91aae11253c@free.fr>
Date: Tue, 21 Feb 2017 09:50:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------88405DFA1529E72C9F36E848"
Archived-At: 
Subject: Re: [OAUTH-WG] review draft-ietf-oauth-native-apps-07
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 08:50:12 -0000

This is a multi-part message in MIME format.
--------------88405DFA1529E72C9F36E848
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit


I *don't thin**k* it's normal to have normative text in the Security 
Considerations, hence I support Samuel's position.

Let us look at the first MUST from RFC 6749 in the Security 
Considerations section:

    The authorization server*_MUST_ *authenticate the client_*whenever possible*_.

This sentence is incorrect. The right sentence should be :

    The authorization server*should *authenticate the client whenever possible.

RFC 6749 is not an example to follow.

Denis


> I do think it's normal to have normative text in the Security 
> Considerations.  RFC6749 has a lengthy Security Considerations section 
>  with a lot of 
> normative text.
>
> Think of it this way: Sections 4 to 7 describe how to use native app 
> URI schemes to perform OAuth flows from the app to browser and back. 
> If you only read those sections, you could have a functioning (but 
> potentially insecure) OAuth flow in a native app. The security section 
> adds some security requirements and clarifications for implementing 
> Sections 4-7, like using PKCE, and more.
>
> Reviewing sub-section by sub-section:
>
> 8.1 Definitely belongs here, as the the whole BCP is about native-app 
> URI schemes, whereas doing OAuth in a WebView doesn't need those (as 
> the client can just pluck out the code from any redirect URI)
> 8.2 Requires that servers who want to follow the native apps BCP 
> support PKCE, and recommends that they reject requests from clients 
> who don't.  This *could* be in the main doc, but since PKCE is an 
> existing thing, and is purely additive from a security perspective, I 
> think this reference works fine. Originally I talked about PKCE more 
> in the doc body, but some reviewers thought it was then a little 
> duplicative of the PKCE doc itself.
> 8.3 This reads like classic security considerations to me, clarifying 
> some details of 7.3
> 8.4 Part of this reads a little new-ish, regarding distinguishing 
> native clients from web ones. But on review, I think could just be 
> re-worded to reference RFC6749 Section 2.1.
> 8.5 This one belongs where it is since the body of the BCP is talking 
> about the code flow.
> 8.6 Totally belongs.
> 8.7 to 8.11 belong IMO, they are security clarifications of 
> long-standing topics.
>
> My methodology when reviewing this was: is the text introducing a new 
> topic directly related to native apps or sections 4-7, or does it 
> discuss an old security topic in the context of native apps, or add 
> security related discussions of the content in 4-7. Of all those, I 
> really only see a bit of new topic related to native apps in 8.4, and 
> in actual fact it that sub-section should probably be reworded since 
> RFC6749 already establishes the public client type, which native apps 
> are and a reference would be more appropriate (which would reduce it 
> to just clarifying an old topic).
>
> What do you think of this analysis? Do you have any specific sections 
> or text you feel are better suited in the document body?  I will take 
> an action item to revise section 8.4.
>
> On Mon, Feb 20, 2017 at 9:57 PM, Samuel Erdtman  > wrote:
>
>     Hi,
>
>     I just had a question on best practice. In this document a large
>     part of the normative text is located under Security Considerations.
>
>     I had previously seen Security Considerations as things to think
>     about when implementing not so much as MUSTs and MUST NOTs.
>
>     I think it is okay to have it this way but it surprised me a bit
>     and wanted to ask if there is any best practice for the Security
>     Considerations section saying what type of information it should
>     include.
>
>     Best Regards
>     Samuel Erdtman
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



--------------88405DFA1529E72C9F36E848
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    


      I don't think it's normal to have normative text in
      the Security Considerations, hence I support Samuel's position.

      

      Let us look at the first MUST from RFC 6749 in the Security
      Considerations section:
      
   The authorization server MUST authenticate the client whenever possible.

This sentence is incorrect. The right sentence should be :

   The authorization server should authenticate the client whenever possible.

RFC 6749 is not an example to follow.

Denis 


      

    

    

      
I do think it's normal to have normative text in
        the Security Considerations.  RFC6749 has a lengthy Security
          Considerations section with a lot of normative text.
        


        

        
Think of it this way: Sections 4 to 7 describe how to use
          native app URI schemes to perform OAuth flows from the app to
          browser and back. If you only read those sections, you could
          have a functioning (but potentially insecure) OAuth flow in a
          native app. The security section adds some security
          requirements and clarifications for implementing Sections 4-7,
          like using PKCE, and more.

        


        

        
Reviewing sub-section by sub-section:

        


        

        
8.1 Definitely belongs here, as the the whole BCP is about
          native-app URI schemes, whereas doing OAuth in a WebView
          doesn't need those (as the client can just pluck out the code
          from any redirect URI)

        
8.2 Requires that servers who want to follow the native
          apps BCP support PKCE, and recommends that they reject
          requests from clients who don't.  This *could* be in the main
          doc, but since PKCE is an existing thing, and is purely
          additive from a security perspective, I think this reference
          works fine. Originally I talked about PKCE more in the doc
          body, but some reviewers thought it was then a little
          duplicative of the PKCE doc itself.

        
8.3 This reads like classic security considerations to me,
          clarifying some details of 7.3

        
8.4 Part of this reads a little new-ish, regarding
          distinguishing native clients from web ones. But on review, I
          think could just be re-worded to reference RFC6749 Section
          2.1.

        
8.5 This one belongs where it is since the body of the BCP
          is talking about the code flow.

        
8.6 Totally belongs.

        
8.7 to 8.11 belong IMO, they are security clarifications of
          long-standing topics. 

        


        

        
My methodology when reviewing this was: is the text
          introducing a new topic directly related to native apps or
          sections 4-7, or does it discuss an old security topic in the
          context of native apps, or add security related discussions of
          the content in 4-7. Of all those, I really only see a bit of
          new topic related to native apps in 8.4, and in actual fact it
          that sub-section should probably be reworded since RFC6749
          already establishes the public client type, which native apps
          are and a reference would be more appropriate (which would
          reduce it to just clarifying an old topic).

        


        

        
What do you think of this analysis? Do you have any
          specific sections or text you feel are better suited in the
          document body?  I will take an action item to revise section
          8.4.

      

      


        
On Mon, Feb 20, 2017 at 9:57 PM, Samuel
          Erdtman <samuel@erdtman.se>
          wrote:

          

            

              

                

                  
Hi,

                    

                  

                  I just had a question on best practice. In this
                  document a large part of the normative text is located
                  under Security Considerations.

                

                

                I had previously seen Security Considerations as things
                to think about when implementing not so much as MUSTs
                and MUST NOTs.

                

              

              I think it is okay to have it this way but it surprised me
              a bit and wanted to ask if there is any best practice for
              the Security Considerations section saying what type of
              information it should include.

              


              

              
Best Regards

                  

              
                  
Samuel Erdtman

                  

                

          

        

        

      

      

      

      

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


    

    


    

  


--------------88405DFA1529E72C9F36E848--


From nobody Tue Feb 21 11:34:39 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA8D129C7E; Tue, 21 Feb 2017 11:34:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.45.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148770567768.19094.1045362986088667412.idtracker@ietfa.amsl.com>
Date: Tue, 21 Feb 2017 11:34:37 -0800
Archived-At: 
Cc: oauth-chairs@ietf.org, smccammon@amsl.com, oauth@ietf.org
Subject: [OAUTH-WG] oauth - New Meeting Session Request for IETF 98
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 19:34:38 -0000

A new meeting session request has just been submitted by Stephanie McCammon, on behalf of the oauth working group.


---------------------------------------------------------
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Stephanie McCammon

Number of Sessions: 2
Length of Session(s):  2.5 Hours, 1 Hour
Number of Attendees: 50
Conflicts to Avoid: 
 First Priority: tokbind tls core saag




People who must be present:
  Derek Atkins
  Kathleen Moriarty
  Hannes Tschofenig

Resources Requested:
  Projector in room

Special Requests:
  Please avoid conflict with sec area BoFs.
---------------------------------------------------------


From nobody Tue Feb 21 12:18:13 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FD51297FE for ; Tue, 21 Feb 2017 12:18:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sn3ciNJeEFWS for ; Tue, 21 Feb 2017 12:18:10 -0800 (PST)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 CD8DC1296EE for ; Tue, 21 Feb 2017 12:18:09 -0800 (PST)
Received: by mail-qt0-x234.google.com with SMTP id b16so71943715qte.0 for ; Tue, 21 Feb 2017 12:18:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=naigTecoKxeN5MtdqbThI6/KpaoayC5lX7YOSEnX0iA=; b=dvFZvyU6JVPfPYlKmTbVpJugPBaZATNRSL/GF0xQr5NESFg8QKnhp4RNtGKaG7EiHQ 5L/hhn9aWrKED/XN2iLicjzYSd9azN5TymZs3ZyksVUK+BVIif2BIEcxVw+GLYhyqJHJ IMGMT9Ix9YLso0vsBcV0ywkPuZeK+R7FzEWgDoABS+5lmNHvQIR660kyUAjptHWvF/uY fFTcVM4x4J+siiJs5txvpK1nNnpMYCSA7BVvgy0r5Rswm275ebLzfNqu3+0wYKd8u/av Agd97cCh3M92CoVT0K6hLakAHpZNsEqC/NvmQz00pnm+pcqH0HrLSuBeOZENz82TFY48 vbnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=naigTecoKxeN5MtdqbThI6/KpaoayC5lX7YOSEnX0iA=; b=ShiRnmsvW3dsZ/855z8V4C5m81VUPIFJ89YbFA/GDka1esA4NOWHGq8BT2MwCj92C9 IkjS33h6waCVjnoMa47DOJmyChljioqcy0qmcqD9KVGglHIkMmx7gE+JCqGmfHT2j5gc RlOTPa3gNcLeTIo20VF7RLK64shEAitOfrzxsu2oHVQH5vFFHEg+NQj/w2MK11sYNVUJ lXSPlyuzovxiY7CJ6o6wN/rSx6u99ncuv8GeGIkDUnvO3EW5tX9Ths7WD7EaaT2lwfOi 5+i40QWqZ4WfqK3TT/q4Qtw+2oSZDj3J8AOHvAmgge4heXNRjdUCtCmdMIdvhs9YQWV4 oJJA==
X-Gm-Message-State: AMke39mweO3C/fKXy1YF+EKn83Lxqg7HO7yyPrgosHw42JCv5OvtLM7EyFKALxyt8LWHRmlYdTxP43nd7j5RV3sR
X-Received: by 10.200.40.38 with SMTP id 35mr25729479qtq.216.1487708288392; Tue, 21 Feb 2017 12:18:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.16.207 with HTTP; Tue, 21 Feb 2017 12:17:47 -0800 (PST)
In-Reply-To: <304c520f-e531-2ac8-f93f-b91aae11253c@free.fr>
References:   <304c520f-e531-2ac8-f93f-b91aae11253c@free.fr>
From: William Denniss 
Date: Tue, 21 Feb 2017 12:17:47 -0800
Message-ID: 
To: Denis 
Content-Type: multipart/alternative; boundary=001a114136da0fb30f0549101479
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] review draft-ietf-oauth-native-apps-07
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 20:18:12 -0000

--001a114136da0fb30f0549101479
Content-Type: text/plain; charset=UTF-8

The only real requirement in that section I guess is the use of PKCE
(8.2).  That requirement could be moved to the body of the doc, while
keeping the longer discussing around code interception in the security
considerations.  To me the remaining text are indeed security best
practices / clarifications.

Other OAuth WG RFCs have requirement level capitalization in the Security
Section like RFC7591. I always assumed these were best-practice security
requirements. But if the style is really not to do this, the requirement
level capitalization could be dropped from that section in the native apps
BCP.

On Tue, Feb 21, 2017 at 12:50 AM, Denis  wrote:

>
> I *don't thin**k* it's normal to have normative text in the Security
> Considerations, hence I support Samuel's position.
>
> Let us look at the first MUST from RFC 6749 in the Security Considerations
> section:
>
>    The authorization server *MUST *authenticate the client *whenever possible*.
> This sentence is incorrect. The right sentence should be :
>
>    The authorization server *should *authenticate the client whenever possible.
>
> RFC 6749 is not an example to follow.
>
> Denis
>
>
> I do think it's normal to have normative text in the Security
> Considerations.  RFC6749 has a lengthy Security Considerations section
>  with a lot of normative
> text.
>
> Think of it this way: Sections 4 to 7 describe how to use native app URI
> schemes to perform OAuth flows from the app to browser and back. If you
> only read those sections, you could have a functioning (but potentially
> insecure) OAuth flow in a native app. The security section adds some
> security requirements and clarifications for implementing Sections 4-7,
> like using PKCE, and more.
>
> Reviewing sub-section by sub-section:
>
> 8.1 Definitely belongs here, as the the whole BCP is about native-app URI
> schemes, whereas doing OAuth in a WebView doesn't need those (as the client
> can just pluck out the code from any redirect URI)
> 8.2 Requires that servers who want to follow the native apps BCP support
> PKCE, and recommends that they reject requests from clients who don't.
> This *could* be in the main doc, but since PKCE is an existing thing, and
> is purely additive from a security perspective, I think this reference
> works fine. Originally I talked about PKCE more in the doc body, but some
> reviewers thought it was then a little duplicative of the PKCE doc itself.
> 8.3 This reads like classic security considerations to me, clarifying some
> details of 7.3
> 8.4 Part of this reads a little new-ish, regarding distinguishing native
> clients from web ones. But on review, I think could just be re-worded to
> reference RFC6749 Section 2.1.
> 8.5 This one belongs where it is since the body of the BCP is talking
> about the code flow.
> 8.6 Totally belongs.
> 8.7 to 8.11 belong IMO, they are security clarifications of long-standing
> topics.
>
> My methodology when reviewing this was: is the text introducing a new
> topic directly related to native apps or sections 4-7, or does it discuss
> an old security topic in the context of native apps, or add security
> related discussions of the content in 4-7. Of all those, I really only see
> a bit of new topic related to native apps in 8.4, and in actual fact it
> that sub-section should probably be reworded since RFC6749 already
> establishes the public client type, which native apps are and a reference
> would be more appropriate (which would reduce it to just clarifying an old
> topic).
>
> What do you think of this analysis? Do you have any specific sections or
> text you feel are better suited in the document body?  I will take an
> action item to revise section 8.4.
>
> On Mon, Feb 20, 2017 at 9:57 PM, Samuel Erdtman  wrote:
>
>> Hi,
>>
>> I just had a question on best practice. In this document a large part of
>> the normative text is located under Security Considerations.
>>
>> I had previously seen Security Considerations as things to think about
>> when implementing not so much as MUSTs and MUST NOTs.
>>
>> I think it is okay to have it this way but it surprised me a bit and
>> wanted to ask if there is any best practice for the Security Considerations
>> section saying what type of information it should include.
>>
>> Best Regards
>> Samuel Erdtman
>>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a114136da0fb30f0549101479
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The only real requirement in that section I guess is =
the use of PKCE (8.2).=C2=A0 That requirement could be moved to the body of=
 the doc, while keeping the longer discussing around code interception in t=
he security considerations.=C2=A0 To me the remaining text are indeed secur=
ity best practices / clarifications.

Other OAuth W=
G RFCs have requirement level capitalization in the Security Section like=
=C2=A0RFC7591. I always assumed these were best-practice security requireme=
nts. But if the style is really not to do this, the requirement level capit=
alization could be dropped from that section in the native apps BCP.
<=
div>
On Tue,=
 Feb 21, 2017 at 12:50 AM, Denis <denis.ietf@free.fr> wrote=
:

 =20
   =20
 =20
  

    


      I don't think it's normal to have normative tex=
t in
      the Security Considerations, hence I support Samuel's position.
      

      Let us look at the first MUST from RFC 6749 in the Security
      Considerations section:
      
   The authorization server MUST authenticate the client <=
u>whenever possible.

This sentence is incorrect. The right sentence should =
be :

   The authorization server should authenticate the client whenever =
possible.

RFC 6749 is not an example to follow.

Denis=20


      

    

    

      
I do think it's normal to have normative text in
        the Security Considerations.=C2=A0 RFC6749 has a lengthy Security
          Considerations section with a lot of normative text.
        


        

        
Think of it this way: Sections 4 to 7 describe how to use
          native app URI schemes to perform OAuth flows from the app to
          browser and back. If you only read those sections, you could
          have a functioning (but potentially insecure) OAuth flow in a
          native app. The security section adds some security
          requirements and clarifications for implementing Sections 4-7,
          like using PKCE, and more.

        


        

        
Reviewing sub-section by sub-section:

        


        

        
8.1 Definitely belongs here, as the the whole BCP is about
          native-app URI schemes, whereas doing OAuth in a WebView
          doesn't need those (as the client can just pluck out the code
          from any redirect URI)

        
8.2 Requires that servers who want to follow the native
          apps BCP support PKCE, and recommends that they reject
          requests from clients who don't.=C2=A0 This *could* be in the=
 main
          doc, but since PKCE is an existing thing, and is purely
          additive from a security perspective, I think this reference
          works fine. Originally I talked about PKCE more in the doc
          body, but some reviewers thought it was then a little
          duplicative of the PKCE doc itself.

        
8.3 This reads like classic security considerations to me,
          clarifying some details of 7.3

        
8.4 Part of this reads a little new-ish, regarding
          distinguishing native clients from web ones. But on review, I
          think could just be re-worded to reference RFC6749 Section
          2.1.

        
8.5 This one belongs where it is since the body of the BCP
          is talking about the code flow.

        
8.6 Totally belongs.

        
8.7 to 8.11 belong IMO, they are security clarifications of
          long-standing topics.=C2=A0

        


        

        
My methodology when reviewing this was: is the text
          introducing a new topic directly related to native apps or
          sections 4-7, or does it discuss an old security topic in the
          context of native apps, or add security related discussions of
          the content in 4-7. Of all those, I really only see a bit of
          new topic related to native apps in 8.4, and in actual fact it
          that sub-section should probably be reworded since RFC6749
          already establishes the public client type, which native apps
          are and a reference would be more appropriate (which would
          reduce it to just clarifying an old topic).

        


        

        
What do you think of this analysis? Do you have any
          specific sections or text you feel are better suited in the
          document body?=C2=A0 I will take an action item to revise section
          8.4.

      

      


        
On Mon, Feb 20, 2017 at 9:57 PM, Samuel
          Erdtman <samuel@erdtman.se>
          wrote:

          

            

              

                

                  
Hi,

                    

                  

                  I just had a question on best practice. In this
                  document a large part of the normative text is located
                  under Security Considerations.

                

                

                I had previously seen Security Considerations as things
                to think about when implementing not so much as MUSTs
                and MUST NOTs.

                

              

              I think it is okay to have it this way but it surprised me
              a bit and wanted to ask if there is any best practice for
              the Security Considerations section saying what type of
              information it should include.

              


              

              
Best Regards

                  

              
                  
Samuel Erdtman

                  

                

          

        

        

      

      

      

      

      
_______________________________________________
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





--001a114136da0fb30f0549101479--


From nobody Tue Feb 21 12:47:23 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24E8129492 for ; Tue, 21 Feb 2017 12:47:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJhjH2u5jE7R for ; Tue, 21 Feb 2017 12:47:18 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 634EF12944C for ; Tue, 21 Feb 2017 12:47:18 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 4FD3BB802E4; Tue, 21 Feb 2017 12:47:18 -0800 (PST)
To: dick.hardt@gmail.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, derek@ihtfp.com, Hannes.Tschofenig@gmx.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20170221204718.4FD3BB802E4@rfc-editor.org>
Date: Tue, 21 Feb 2017 12:47:18 -0800 (PST)
Archived-At: 
Cc: text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, oauth@ietf.org, gaur.1@iitj.ac.in, charset=UTF-8@rfc-editor.org
Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (4945)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 20:47:23 -0000

The following errata report has been submitted for RFC6749,
"The OAuth 2.0 Authorization Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4945

--------------------------------------
Type: Editorial
Reported by: Abhimanyu Singh Gaur 

Section: 4.1.4

Original Text
-------------
If the access token request is valid and authorized, the
   authorization server issues an access token and optional refresh
   token as described in Section 5.1.  If the request client
   authentication failed or is invalid, the authorization server returns
   an error response as described in Section 5.2.

Corrected Text
--------------
If the access token request is valid and authorized, the
   authorization server issues an access token and optional refresh
   token as described in Section 5.1.  If the request failed client
   authentication or is invalid, the authorization server returns
   an error response as described in Section 5.2.

Notes
-----
In the 2nd line, "request failed" makes more sense than the original text.
The 1st paragraph of section 5 in the document and the para just before section 5 also state "If the request failed client authentication or ..." instead of what is currently mentioned in section 4.1.4.

It is just a typing mistake, I think the words got exchanged during typing.
Please, correct it.

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

--------------------------------------
RFC6749 (draft-ietf-oauth-v2-31)
--------------------------------------
Title               : The OAuth 2.0 Authorization Framework
Publication Date    : October 2012
Author(s)           : D. Hardt, Ed.
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Tue Feb 21 12:48:51 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BC01294E2 for ; Tue, 21 Feb 2017 12:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 835q1yjV9Kgl for ; Tue, 21 Feb 2017 12:48:49 -0800 (PST)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 EA59A12944C for ; Tue, 21 Feb 2017 12:48:45 -0800 (PST)
Received: by mail-yw0-x22f.google.com with SMTP id p77so3106206ywg.1 for ; Tue, 21 Feb 2017 12:48:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=utVXTSTWErdGUMuq1eGmwKvSJO86dOpBW3c2fUTw0uE=; b=H+0jBBQ2iTP8fKm3P3U+CVmPNltQmGUo8HC5Bz0cihney7lF3LnqJpdsZOFGBWkGBh 68hASiQDw7CxbKiM5OmULSCe5eJSq5qMkIzV470ohjotups4F/8X7kyzgbFqb7A3nczW GrLlzu2sZ8lWYRTbn5MEH1tNZFQjMSPKuvNJ0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=utVXTSTWErdGUMuq1eGmwKvSJO86dOpBW3c2fUTw0uE=; b=b5yzu4s2A2qZAyji8fDB8oQ+q3Bwmjdmwv6/Z91mc1PeBYiYVuLjDkMOI5fE/AgQc3 hV701wfFmA/bJNtBlMlUL77gmxbc6JS2KtuNsuAb49qt6pjJjPM+ZkUVDB4aOoIJ3k/U 0iaFHWG8eUuGfn+RpaQkjbEJJaJjKYdh/FYolLwB/C7AJyOD1/bsIOpaQ464Ck6/g2ny o3NeJHqI/Vz4W0bhZohx52SlZRJyjCKv3m+54AGbwJBsLOf9nqJcY/jcWMihTth5ppX1 u4hSAvLE/sl7ewG96J+A5Eqch3/XhIOuiU66FvQjqFtult2MnN/ZBBvVdt51RM8+AOTL SeJA==
X-Gm-Message-State: AMke39lWqlZK5foqTu7IsvfTBYfHAPCokQdspbIEV9TPzcj/SP5KRT/bocoHU0Kyc6GO1XJp7CojszXlm8Kto3uB
X-Received: by 10.129.49.73 with SMTP id x70mr4206116ywx.171.1487710125109; Tue, 21 Feb 2017 12:48:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.126.131 with HTTP; Tue, 21 Feb 2017 12:48:14 -0800 (PST)
In-Reply-To: <01f901d28c1d$a56fbf30$f04f3d90$@nri.co.jp>
References: <01f901d28c1d$a56fbf30$f04f3d90$@nri.co.jp>
From: Brian Campbell 
Date: Tue, 21 Feb 2017 13:48:14 -0700
Message-ID: 
To: Nat Sakimura 
Content-Type: multipart/alternative; boundary=001a1140704089b69305491081be
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-token-binding-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 20:48:50 -0000

--001a1140704089b69305491081be
Content-Type: text/plain; charset=UTF-8

Adding some examples would probably be helpful, yes. Thanks. Some will
maybe be more possible/sensible than others (like I don't know what exactly
to show in an example of binding a refresh token) but I'll endeavor to add
some useful examples in a future revision.


On Tue, Feb 21, 2017 at 1:36 AM, Nat Sakimura  wrote:

> Hi OAuthers:
>
>
>
> I was reading draft-ietf-oauth-token-binding-01 this afternoon and
> thought that examples for each subsection of 2 and 3 would be helpful.
>
>
>
> Is it possible/sensible to add them?
>
>
>
> Best,
>
>
>
> Nat
>
> --
>
> PLEASE READ :This e-mail is confidential and intended for the
>
> named recipient only. If you are not an intended recipient,
>
> please notify the sender  and delete this e-mail.
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a1140704089b69305491081be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Adding some examples would probably be helpful, yes. =
Thanks. Some will maybe be more possible/sensible than others (like I don't know what exactly=
 to show in an example of binding a refresh token) but I'll endeavor to=
 add some useful examples in a future revision. 


On Tue, Feb 21, 2017 at =
1:36 AM, Nat Sakimura <n-sakimura@nri.co.jp> wrote:
Hi OAuthers: <=
u>
=C2=A0
I was reading draft-ietf-oauth-toke=
n-binding-01 this afternoon and thought that examples for each subsect=
ion of 2 and 3 would be helpful. 
=C2=A0<=
/span>
Is it possible/sensible to add them? 
=C2=
=A0
Best, 
=C2=A0
=

Nat<=
u>
--
PLEASE READ :This e-mail is conf=
idential and intended for the
named recipient only. If =
you are not an intended recipient,
please notify the se=
nder=C2=A0 and delete this e-mail.
=C2=A0

=
_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





--001a1140704089b69305491081be--


From nobody Tue Feb 21 15:09:32 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF571289B0 for ; Tue, 21 Feb 2017 15:09:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkJ5bY6rKl07 for ; Tue, 21 Feb 2017 15:09:28 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 A649C120726 for ; Tue, 21 Feb 2017 15:09:28 -0800 (PST)
X-AuditID: 12074425-bc3ff70000003acd-a8-58acc8a56863
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  (Symantec Messaging Gateway) with SMTP id 72.90.15053.5A8CCA85; Tue, 21 Feb 2017 18:09:26 -0500 (EST)
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 v1LN9OOH023091; Tue, 21 Feb 2017 18:09:25 -0500
Received: from [172.16.208.198] (173-166-14-1-newengland.hfc.comcastbusiness.net [173.166.14.1]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v1LN9Dkx030374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Feb 2017 18:09:20 -0500
From: Justin Richer 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_3CDE03D4-FF70-417F-A394-187C98362952"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Tue, 21 Feb 2017 18:09:03 -0500
In-Reply-To: 
To: William Denniss 
References:   <304c520f-e531-2ac8-f93f-b91aae11253c@free.fr> 
X-Mailer: Apple Mail (2.3259)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixCmqrbvsxJoIg6Yp0hbru+wsTr59xWax aU4zuwOzR/+6z6weCzaVeixZ8pMpgDmKyyYlNSezLLVI3y6BK+PPHqGCD62MFbuaHzM1MO7J 7GLk5JAQMJF427uFvYuRi0NIoI1J4tDSZ2wQzkZGiWt7dkJl7jJJvGmawwrSwiagKjF9TQsT iM0rYCVxeuZcdhCbWSBJYsKhXlaIuL7E7DOXWEBsYQE7iUv3rgFN5eBgAert7TMHCXMKBEpM X3eTFaLVWWLPhLlsILaIgKbEy7MHWCD29jNJvHv2kg3iVFmJt7+WME9g5J+FZN0sJOsg4toS yxa+ZoawNSX2dy/HIq4h0fltIusCRrZVjLIpuVW6uYmZOcWpybrFyYl5ealFuhZ6uZkleqkp pZsYQaHO7qK6g3HOX69DjAIcjEo8vA/c10QIsSaWFVfmHmKU5GBSEuVdPhMoxJeUn1KZkVic EV9UmpNafIhRgoNZSYR30k6gHG9KYmVValE+TEqag0VJnFdcozFCSCA9sSQ1OzW1ILUIJivD waEkwRtzHKhRsCg1PbUiLTOnBCHNxMEJMpwHaPiUYyDDiwsSc4sz0yHypxh1OaZMvfiSSYgl Lz8vVUqcdx9IkQBIUUZpHtwcUIpau4yP8RWjONBbwrydIOt4gOkNbtIroCVMQEtueqwEWVKS iJCSamAUrExLetS4h6tQpOfJIZ3Kqz1KhkIfpVc1PP3Bdcjt4eNTEecK/ok9eL2bd+n+6Oiv 61yvcR5RFz2X35YXqvh2Xw/f04SeNdqT6ux190pZJStxSjca3w1xWiva0BObKclyuV97moLa 9lNab/X/LUrM/3Be+5iR65eXYuKJ1wO/B0rGrll3p06JpTgj0VCLuag4EQDsqt4JLAMAAA==
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] review draft-ietf-oauth-native-apps-07
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Feb 2017 23:09:30 -0000

--Apple-Mail=_3CDE03D4-FF70-417F-A394-187C98362952
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

When I brought RFCs 7591, 7592, and 7662 up through the finalization =
process, I learned that there are two camps out there on normative =
requirements in the security considerations section. Some like them, as =
long as they don=E2=80=99t contradict requirements/advice in previous =
sections, and some don=E2=80=99t like them, preferring all normative =
material be in the =E2=80=9Cbody=E2=80=9D of the spec itself. I was =
given the impression that it was more of a stylistic choice than =
anything, but I can only speak from my personal experience.

 =E2=80=94 Justin

> On Feb 21, 2017, at 3:17 PM, William Denniss  =
wrote:
>=20
> The only real requirement in that section I guess is the use of PKCE =
(8.2).  That requirement could be moved to the body of the doc, while =
keeping the longer discussing around code interception in the security =
considerations.  To me the remaining text are indeed security best =
practices / clarifications.
>=20
> Other OAuth WG RFCs have requirement level capitalization in the =
Security Section like RFC7591. I always assumed these were best-practice =
security requirements. But if the style is really not to do this, the =
requirement level capitalization could be dropped from that section in =
the native apps BCP.
>=20
> On Tue, Feb 21, 2017 at 12:50 AM, Denis > wrote:
>=20
> I don't think it's normal to have normative text in the Security =
Considerations, hence I support Samuel's position.
>=20
> Let us look at the first MUST from RFC 6749 in the Security =
Considerations section:
>    The authorization server MUST authenticate the client whenever =
possible.
>=20
> This sentence is incorrect. The right sentence should be :
>=20
>    The authorization server should authenticate the client whenever =
possible.
>=20
> RFC 6749 is not an example to follow.
>=20
> Denis=20
>=20
>> I do think it's normal to have normative text in the Security =
Considerations.  RFC6749 has a lengthy Security Considerations section =
 with a lot of normative =
text.
>>=20
>> Think of it this way: Sections 4 to 7 describe how to use native app =
URI schemes to perform OAuth flows from the app to browser and back. If =
you only read those sections, you could have a functioning (but =
potentially insecure) OAuth flow in a native app. The security section =
adds some security requirements and clarifications for implementing =
Sections 4-7, like using PKCE, and more.
>>=20
>> Reviewing sub-section by sub-section:
>>=20
>> 8.1 Definitely belongs here, as the the whole BCP is about native-app =
URI schemes, whereas doing OAuth in a WebView doesn't need those (as the =
client can just pluck out the code from any redirect URI)
>> 8.2 Requires that servers who want to follow the native apps BCP =
support PKCE, and recommends that they reject requests from clients who =
don't.  This *could* be in the main doc, but since PKCE is an existing =
thing, and is purely additive from a security perspective, I think this =
reference works fine. Originally I talked about PKCE more in the doc =
body, but some reviewers thought it was then a little duplicative of the =
PKCE doc itself.
>> 8.3 This reads like classic security considerations to me, clarifying =
some details of 7.3
>> 8.4 Part of this reads a little new-ish, regarding distinguishing =
native clients from web ones. But on review, I think could just be =
re-worded to reference RFC6749 Section 2.1.
>> 8.5 This one belongs where it is since the body of the BCP is talking =
about the code flow.
>> 8.6 Totally belongs.
>> 8.7 to 8.11 belong IMO, they are security clarifications of =
long-standing topics.=20
>>=20
>> My methodology when reviewing this was: is the text introducing a new =
topic directly related to native apps or sections 4-7, or does it =
discuss an old security topic in the context of native apps, or add =
security related discussions of the content in 4-7. Of all those, I =
really only see a bit of new topic related to native apps in 8.4, and in =
actual fact it that sub-section should probably be reworded since =
RFC6749 already establishes the public client type, which native apps =
are and a reference would be more appropriate (which would reduce it to =
just clarifying an old topic).
>>=20
>> What do you think of this analysis? Do you have any specific sections =
or text you feel are better suited in the document body?  I will take an =
action item to revise section 8.4.
>>=20
>> On Mon, Feb 20, 2017 at 9:57 PM, Samuel Erdtman > wrote:
>> Hi,
>>=20
>> I just had a question on best practice. In this document a large part =
of the normative text is located under Security Considerations.
>>=20
>> I had previously seen Security Considerations as things to think =
about when implementing not so much as MUSTs and MUST NOTs.
>>=20
>> I think it is okay to have it this way but it surprised me a bit and =
wanted to ask if there is any best practice for the Security =
Considerations section saying what type of information it should =
include.
>>=20
>> Best Regards
>> Samuel Erdtman
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

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

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


--Apple-Mail=_3CDE03D4-FF70-417F-A394-187C98362952
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

When I brought RFCs 7591, 7592, and 7662 up through the =
finalization process, I learned that there are two camps out there on =
normative requirements in the security considerations section. Some like =
them, as long as they don=E2=80=99t contradict requirements/advice in =
previous sections, and some don=E2=80=99t like them, preferring all =
normative material be in the =E2=80=9Cbody=E2=80=9D of the spec itself. =
I was given the impression that it was more of a stylistic choice than =
anything, but I can only speak from my personal experience.

 =E2=80=94 =
Justin

On Feb 21, 2017, at 3:17 PM, William Denniss =
<wdenniss@google.com> wrote:

The only real =
requirement in that section I guess is the use of PKCE (8.2).  That =
requirement could be moved to the body of the doc, while keeping the =
longer discussing around code interception in the security =
considerations.  To me the remaining text are indeed security best =
practices / clarifications.

Other OAuth WG RFCs have requirement level capitalization in =
the Security Section like RFC7591. I always assumed these were =
best-practice security requirements. But if the style is really not to =
do this, the requirement level capitalization could be dropped from that =
section in the native apps BCP.

On =
Tue, Feb 21, 2017 at 12:50 AM, Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    


      I don't think it's normal to =
have normative text in
      the Security Considerations, hence I support Samuel's position.

      

      Let us look at the first MUST from RFC 6749 in the Security
      Considerations section:
      
   =
The authorization server MUST =
authenticate the client whenever =
possible.

This sentence is incorrect. The right =
sentence should be :

   The authorization server should authenticate the =
client whenever possible.

RFC 6749 is not an example to follow.

Denis=20


      

    

    

      
I do think it's normal to have =
normative text in
        the Security Considerations.  RFC6749 has a lengthy Security
          Considerations section with a lot of normative text.
        


        

        
Think of it this way: Sections 4 to 7 describe =
how to use
          native app URI schemes to perform OAuth flows from the app to
          browser and back. If you only read those sections, you could
          have a functioning (but potentially insecure) OAuth flow in a
          native app. The security section adds some security
          requirements and clarifications for implementing Sections 4-7,
          like using PKCE, and more.

        


        

        
Reviewing sub-section by sub-section:

        


        

        
8.1 Definitely belongs here, as the the whole =
BCP is about
          native-app URI schemes, whereas doing OAuth in a WebView
          doesn't need those (as the client can just pluck out the code
          from any redirect URI)

        
8.2 Requires that servers who want to follow the =
native
          apps BCP support PKCE, and recommends that they reject
          requests from clients who don't.  This *could* be in the =
main
          doc, but since PKCE is an existing thing, and is purely
          additive from a security perspective, I think this reference
          works fine. Originally I talked about PKCE more in the doc
          body, but some reviewers thought it was then a little
          duplicative of the PKCE doc itself.

        
8.3 This reads like classic security =
considerations to me,
          clarifying some details of 7.3

        
8.4 Part of this reads a little new-ish, =
regarding
          distinguishing native clients from web ones. But on review, I
          think could just be re-worded to reference RFC6749 Section
          2.1.

        
8.5 This one belongs where it is since the body =
of the BCP
          is talking about the code flow.

        
8.6 Totally belongs.

        
8.7 to 8.11 belong IMO, they are security =
clarifications of
          long-standing topics. 

        


        

        
My methodology when reviewing this was: is the =
text
          introducing a new topic directly related to native apps or
          sections 4-7, or does it discuss an old security topic in the
          context of native apps, or add security related discussions of
          the content in 4-7. Of all those, I really only see a bit of
          new topic related to native apps in 8.4, and in actual fact it
          that sub-section should probably be reworded since RFC6749
          already establishes the public client type, which native apps
          are and a reference would be more appropriate (which would
          reduce it to just clarifying an old topic).

        


        

        
What do you think of this analysis? Do you have =
any
          specific sections or text you feel are better suited in the
          document body?  I will take an action item to revise =
section
          8.4.

      

      


        
On Mon, Feb 20, 2017 at 9:57 PM, =
Samuel
          Erdtman <samuel@erdtman.se>
          wrote:

          

            

              

                

                  
Hi,

                    

                  

                  I just had a question on best practice. In this
                  document a large part of the normative text is located
                  under Security Considerations.

                

                

                I had previously seen Security Considerations as things
                to think about when implementing not so much as MUSTs
                and MUST NOTs.

                

              

              I think it is okay to have it this way but it surprised me
              a bit and wanted to ask if there is any best practice for
              the Security Considerations section saying what type of
              information it should include.

              


              

              
Best Regards

                  

              
                  
Samuel Erdtman

                  

                

          

        

        

      

      

      

      

      
_______________________________________________
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

=

--Apple-Mail=_3CDE03D4-FF70-417F-A394-187C98362952--


From nobody Thu Feb 23 06:46:29 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1969312989B for ; Thu, 23 Feb 2017 06:46:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zalando-de.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVXU0nHwcwjj for ; Thu, 23 Feb 2017 06:46:26 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329EA1297CA for ; Thu, 23 Feb 2017 06:46:26 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id v186so173983914wmd.0 for ; Thu, 23 Feb 2017 06:46:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zalando-de.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=17evyP5A5wlrYlGNv5sfbCUvspQ4O2zfe1g9rSry3HA=; b=xm8qtOVfPANiNq+Bk/3Xc2C3YKvmlz48+j7TbfXF5tVuhIiFQUerzBtI9xTrTtXG4y qZhOqnVZERCQM348siCUuh1XOBMBrRRnndjrsRBvffht/S1s0v7aalLdV7yvtwlxAYQ8 3isORwst7Dcmlu58gIX8N7r9Scz1wiU/Are8LpdGgTp4wipQX2h3YQ2pYLF/8vXji6Ko nt5tR8y7EMjy4zUJWS4HrtheTW6M/8xi8xhN0nmURgGWO5qCcqQFsMLgeAUDr0+hixKW ty+irCLCcACrV5fFc3pCSCYpIqzsjVwWpHz8w4KDSIDUQc5+DMS2UKjX7bhLD6PlR2hi 2uSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=17evyP5A5wlrYlGNv5sfbCUvspQ4O2zfe1g9rSry3HA=; b=NsILd8+sprDYgKnOQaFeC/wTih8ADK2v+2cw4UFgeXTz0RvY/l74kVaN0Z06Sfkbik V+Dq4E2BMTY15sbzFfi/bZu05410NUBb2lt6Z3LcJ0lLT+AINU2q7Uv9Fm+BTblYHwR7 LE/1XAJjzVCZx5fB1y9Htv7YiCTGgI2iRSD0nC+a8MzFm0pHVd7qfTAWi1kDPlosDT3D g/zIOrrNpFEALvlYtmeQV74afSkvaBPLLB/kkAD3S1eqxxQYtEmGPc9mFgn/cWDgAP03 vnkm6kI3ibd34CwSOIEBGJT2HZFwbgziY5p32dDTHF1Qkx8A6gLj0G84xUDb6LcckTc+ m2SA==
X-Gm-Message-State: AMke39kECHmvY9/7rAmtr5LO3K2v/v2r1mBI104hwCdPUuRGrQlI0Po5Se8Ru+yrSKW2g7F7
X-Received: by 10.28.126.12 with SMTP id z12mr3248793wmc.84.1487861184378; Thu, 23 Feb 2017 06:46:24 -0800 (PST)
Received: from zalando-09663.corp.ad.zalando.net ([185.85.220.194]) by smtp.gmail.com with ESMTPSA id 65sm6286716wri.53.2017.02.23.06.46.23 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Feb 2017 06:46:23 -0800 (PST)
From: Jan Brennenstuhl 
Content-Type: multipart/alternative; boundary="Apple-Mail=_B7BB17F1-70FA-4FD8-8808-5A87EDF111AF"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Message-Id: 
Date: Thu, 23 Feb 2017 15:46:22 +0100
To: oauth@ietf.org
X-Mailer: Apple Mail (2.3259)
Archived-At: 
Subject: [OAUTH-WG] [oauth-token-exchange] Composite Token Design
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Feb 2017 14:46:28 -0000

--Apple-Mail=_B7BB17F1-70FA-4FD8-8808-5A87EDF111AF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hey everyone,

Let me shortly introduce myself - My name is Jan, I do IAM at Zalando =
SE.

I am writing, because I like to get a better understanding of the =
reasoning behind a fundamental conceptual decision that was made in the =
oauth-token-exchange draft.

The draft describes one possible design of a composite token: an 'act' =
claim in a representee token, meaning that a regular principal token =
gives the information about a possible delegate/ agent a piggyback.=20

In my eyes, this is not quite intuitive nor the most secure solution as:

the current approach cloaks the true nature of the delegation as the =
actual actor is not represented by/ in the primary token,
the current approach would be entirely transparent for old/ legacy =
systems which do not know about a possible act claim. Those =
applications, would support delegation simply because they do not know =
any better. For them, the intended delegation would look like a true =
impersonation.

As delegation usually is a highly security sensitive thing to do, I =
personally would prefer the probably more secure approach of defining a =
primary agent token with a nested representee token/ information. This =
would lead to systems not just silently supporting delegation (without =
knowing about it). They would need to explicitly support the spec if =
they want to support delegation.

My questions now are:
am I missing something here,
do you share my worries,=20
what are the actual reasons for the current composite token design?

Would be great if you could provide some background info on why you =
chose to follow the current approach.

Thanks, Jan=

--Apple-Mail=_B7BB17F1-70FA-4FD8-8808-5A87EDF111AF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Hey =
everyone,

Let me shortly introduce myself - My name is Jan, I do IAM at =
Zalando SE.

I am writing, because =
I like to get a better understanding of the reasoning behind a =
fundamental conceptual decision that was made in the =
oauth-token-exchange draft.

The draft describes =
one possible design of a composite token: an 'act' claim in a =
representee token, meaning that a regular principal token gives the =
information about a possible delegate/ agent a piggyback. =


In my eyes, this is not quite intuitive nor the most secure =
solution as:

  • the current approach cloaks the true nature of the delegation =
as the actual actor is not represented by/ in the primary =
token,
  • the current approach would be entirely transparent for old/ =
legacy systems which do not know about a possible act claim. Those =
applications, would support delegation simply because they do not know =
any better. For them, the intended delegation would look like a true =
impersonation.

As delegation usually =
is a highly security sensitive thing to do, I personally would prefer =
the probably more secure approach of defining a primary agent token with =
a nested representee token/ information. This would lead to systems not =
just silently supporting delegation (without knowing about it). They =
would need to explicitly support the spec if they want to support =
delegation.

My questions now =
are:
  • am I missing something =
here,
  • do you share my worries, 
  • what are the actual reasons for the current composite token =
design?

Would be great if you =
could provide some background info on why you chose to follow the =
current approach.

Thanks, Jan=

--Apple-Mail=_B7BB17F1-70FA-4FD8-8808-5A87EDF111AF--


From nobody Fri Feb 24 13:55:27 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E7912951D; Fri, 24 Feb 2017 13:55:25 -0800 (PST)
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.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148797332573.3278.6515135380852468551.idtracker@ietfa.amsl.com>
Date: Fri, 24 Feb 2017 13:55:25 -0800
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 21:55:26 -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 of the IETF.

        Title           : OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution
        Authors         : John Bradley
                          Phil Hunt
                          Michael B. Jones
                          Hannes Tschofenig
	Filename        : draft-ietf-oauth-pop-key-distribution-03.txt
	Pages           : 18
	Date            : 2017-02-24

Abstract:
   RFC 6750 specified the bearer token concept for securing access to
   protected resources.  Bearer tokens need to be protected in transit
   as well as at rest.  When a client requests access to a protected
   resource it hands-over the bearer token to the resource server.

   The OAuth 2.0 Proof-of-Possession security concept extends bearer
   token security and requires the client to demonstrate possession of a
   key when accessing a protected resource.

   This document describes how the client obtains this keying material
   from the authorization server.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-pop-key-distribution-03


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

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


From nobody Fri Feb 24 13:59:04 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC1E12951D for ; Fri, 24 Feb 2017 13:59:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUyyJ5ahpci4 for ; Fri, 24 Feb 2017 13:59:02 -0800 (PST)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21531293F9 for ; Fri, 24 Feb 2017 13:59:01 -0800 (PST)
Received: by mail-qt0-x22e.google.com with SMTP id n21so27728893qta.1 for ; Fri, 24 Feb 2017 13:59:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:references:to:date; bh=APOGTnu1Hw26SJ5PJZj8Vu5370F169WBahrnCvPqROM=; b=gPqepGfp7h3a/a/sSrg2PesdIh/gNJnungz78BnWbzab0gzJiSiWlHP69ZPaMd+Kw5 0XOm3dNkOKfCRz1TI37T5ZSP/pIiiXVSo4M/iCjCP592YoiHsy5hmEoy/06Vjo4TSn7x k4tT28smbxvbSY85Zs9EZNgBdrighisDzHWmWjpZvAAcZ4O4Wmr7PKfcIcq0IDAsLbus qOVBPcO9T+e2zi/SCe1lbfnD96noy/Yu8TVQqpqQBuvgxQFqN0ljouScrRlz4c2w9MQ1 BMYzRBvpjGwCuOdrfPrDbXOIIXh5oX9dlSM3Zd7DIomOET/ENyRui5i2nCK8wPsOWC4e 9i+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=APOGTnu1Hw26SJ5PJZj8Vu5370F169WBahrnCvPqROM=; b=Hd6+Cso912mVImXF+afBm+mpNk782JGrd3rUc+xSX5njwr4eDtAZyJY2JxheIvxT2W it0IXXqV3X6S7TI00kfVWCLz+V0NKY80XWRwpBQgSRz39gD6x2errYcVJQblx4wS+pbf uxHBe53IWEpezb2YPFfiJOR4SEl+yzQU4Z77tNX34q7mfqdl1YC8udaluo6wPI1Sioz1 IJ+NUNmq4w0JULmfGN6frZWQ9zM7VuJoiQn1A52dYNk8wOccmko8BrOccK7hWbKUs7vz xYeR/IndL4RWfTY3h4OFw2BiuCGHEkjhNGIzwhTOsYbaiGveeVSH3px/qR62Vpg8+6/6 ty2A==
X-Gm-Message-State: AMke39kAtHpfdJyJDZmuePlBNcd9afThgZvJlhIqfbvdBVFbW5b0WzJsecghRnXJTENXeTAm
X-Received: by 10.200.38.117 with SMTP id v50mr4830225qtv.230.1487973540650; Fri, 24 Feb 2017 13:59:00 -0800 (PST)
Received: from [192.168.86.130] ([191.115.25.29]) by smtp.gmail.com with ESMTPSA id h33sm5610341qtc.42.2017.02.24.13.58.59 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 13:58:59 -0800 (PST)
From: John Bradley 
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Message-Id: 
References: <148797332573.3278.6515135380852468551.idtracker@ietfa.amsl.com>
To: "" 
Date: Fri, 24 Feb 2017 18:58:57 -0300
X-Mailer: Apple Mail (2.3259)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11410570571ab905494dd6c0"
Archived-At: 
Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 21:59:03 -0000

--001a11410570571ab905494dd6c0
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_5DF00118-819E-4F37-82CF-481D2EE8E789"


--Apple-Mail=_5DF00118-819E-4F37-82CF-481D2EE8E789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I updated the references but haven't made any other changes.

I had some questions about it so though it was worth keeping alive =
at-least for discussion.

There have been some other questions and proposed changes. =20

I will take a look through them and see if what may be worth updating.

John B.

> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: [OAUTH-WG] I-D Action: =
draft-ietf-oauth-pop-key-distribution-03.txt
> Date: February 24, 2017 at 6:55:25 PM GMT-3
> To: 
> Cc: oauth@ietf.org
>=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 of the =
IETF.
>=20
>        Title           : OAuth 2.0 Proof-of-Possession: Authorization =
Server to Client Key Distribution
>        Authors         : John Bradley
>                          Phil Hunt
>                          Michael B. Jones
>                          Hannes Tschofenig
> 	Filename        : draft-ietf-oauth-pop-key-distribution-03.txt
> 	Pages           : 18
> 	Date            : 2017-02-24
>=20
> Abstract:
>   RFC 6750 specified the bearer token concept for securing access to
>   protected resources.  Bearer tokens need to be protected in transit
>   as well as at rest.  When a client requests access to a protected
>   resource it hands-over the bearer token to the resource server.
>=20
>   The OAuth 2.0 Proof-of-Possession security concept extends bearer
>   token security and requires the client to demonstrate possession of =
a
>   key when accessing a protected resource.
>=20
>   This document describes how the client obtains this keying material
>   from the authorization server.
>=20
>=20
> The IETF datatracker status page for this draft is:
> =
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/
>=20
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03
>=20
> A diff from the previous version is available at:
> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-key-distribution-=
03
>=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=_5DF00118-819E-4F37-82CF-481D2EE8E789
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

I updated the references but haven't made any other =
changes.

I had some =
questions about it so though it was worth keeping alive at-least for =
discussion.

There have been some other questions and proposed changes. =
 

I will =
take a look through them and see if what may be worth =
updating.

John =
B.

Begin forwarded message:

From: =
internet-drafts@ietf.org
Subject: =
[OAUTH-WG] I-D =
Action: draft-ietf-oauth-pop-key-distribution-03.txt
Date: =
February 24, 2017 at 6:55:25 PM =
GMT-3
To: =
<i-d-announce@ietf.org>
Cc: oauth@ietf.org


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

 =
       Title =
          : OAuth 2.0 =
Proof-of-Possession: Authorization Server to Client Key Distribution
        Authors =
        : John Bradley
 =
            &n=
bsp;           &nbs=
p;Phil Hunt
 =
            &n=
bsp;           &nbs=
p;Michael B. Jones
 =
            &n=
bsp;           &nbs=
p;Hannes Tschofenig
	Filename =
       : =
draft-ietf-oauth-pop-key-distribution-03.txt
	Pages =
          : 18
	=
Date =
           : =
2017-02-24

Abstract:
 =
  RFC 6750 specified the bearer token concept for securing =
access to
   protected resources.  Bearer =
tokens need to be protected in transit
   as =
well as at rest.  When a client requests access to a protected
   resource it hands-over the bearer token to the =
resource server.

   The OAuth 2.0 =
Proof-of-Possession security concept extends bearer
 =
  token security and requires the client to demonstrate =
possession of a
   key when accessing a =
protected resource.

   This =
document describes how the client obtains this keying material
   from the authorization server.


The IETF datatracker status page for this =
draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distr=
ibution/

There's also a htmlized =
version available at:
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi=
on-03

A diff from the previous version is =
available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-key-di=
stribution-03


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

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

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

=

--Apple-Mail=_5DF00118-819E-4F37-82CF-481D2EE8E789--

--001a11410570571ab905494dd6c0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG
A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy
MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl
ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1
cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW
pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW
/qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G
sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt
MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G
Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g
JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw
BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1
c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v
b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er
wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y
G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum
NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG
NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2
ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3
b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX
DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD
VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0
ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng
TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt
Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH
E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA
Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl
ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL
VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6
xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG
A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4
dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5
gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW
t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0
cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda
e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB
mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2
IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw
MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB
o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM
Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f
a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN
M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR
AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU
Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l
BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9
MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0
L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy
NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp
ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3
DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL
5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM
JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N
BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU
jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y
FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIER4iynRxFCK/s//6vH+ehuxcWI3
QC1lglREnf+53B1eMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3
MDIyNDIxNTkwMFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG
CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl
AwQCATANBgkqhkiG9w0BAQEFAASCAQDORSs86Cq0QpH32ria2jUQS8MtgXgLHBTP5/J0kWzpG58u
mYXTYEiThc43RgUbSMJ2jqUGdlUAMdzgiEexQCHpAGP+vyjo0v2UXpQ/ksAbWczgLOA3YqSR5/AO
/vYqyOX0Gk4a7u92955AvZk4DOsZua9lhg0CJxAE9rQlQEsNaeAlNVhs5FUaRzLe+BOzmUS3Ccvl
4L5puXQCGVWpv2rKhhSurpo2NiyNLFteI4ZnkRLcoSIoLrX6Ty/qSwi5+mR6w4YzSU5/brdSf6wt
pcWXCxHujSJgiN7P4uvHyf4Foeh1Cyz78YyFC3Z/V50nDQ7S5ob0xvLfCICCpO2GqexX
--001a11410570571ab905494dd6c0--


From nobody Fri Feb 24 15:34:11 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC11B129541 for ; Fri, 24 Feb 2017 15:34:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.088
X-Spam-Level: 
X-Spam-Status: No, score=-6.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.887, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0cB7QXJoPfS for ; Fri, 24 Feb 2017 15:34:07 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 D65E7129526 for ; Fri, 24 Feb 2017 15:34:06 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v1ONY4eP000916 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Feb 2017 23:34:04 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v1ONY3pk029368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Feb 2017 23:34:03 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v1ONY0u1020540; Fri, 24 Feb 2017 23:34:02 GMT
Received: from [192.168.1.16] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 Feb 2017 15:34:00 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_B9028F13-8E28-4B8C-ACFD-2FF93119FD79"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Phil Hunt 
In-Reply-To: 
Date: Fri, 24 Feb 2017 15:33:55 -0800
Message-Id: 
References: <148797332573.3278.6515135380852468551.idtracker@ietfa.amsl.com> 
To: John Bradley 
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 23:34:09 -0000

--Apple-Mail=_B9028F13-8E28-4B8C-ACFD-2FF93119FD79
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I have been wondering about that myself. Interest seems to wained with =
the TOKBIND work emerging. Maybe I am wrong about that?

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com =
phil.hunt@oracle.com =








> On Feb 24, 2017, at 1:58 PM, John Bradley  wrote:
>=20
> I updated the references but haven't made any other changes.
>=20
> I had some questions about it so though it was worth keeping alive =
at-least for discussion.
>=20
> There have been some other questions and proposed changes. =20
>=20
> I will take a look through them and see if what may be worth updating.
>=20
> John B.
>=20
>> Begin forwarded message:
>>=20
>> From: internet-drafts@ietf.org 
>> Subject: [OAUTH-WG] I-D Action: =
draft-ietf-oauth-pop-key-distribution-03.txt
>> Date: February 24, 2017 at 6:55:25 PM GMT-3
>> To: >
>> Cc: oauth@ietf.org 
>>=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 of the =
IETF.
>>=20
>>        Title           : OAuth 2.0 Proof-of-Possession: Authorization =
Server to Client Key Distribution
>>        Authors         : John Bradley
>>                          Phil Hunt
>>                          Michael B. Jones
>>                          Hannes Tschofenig
>> 	Filename        : draft-ietf-oauth-pop-key-distribution-03.txt
>> 	Pages           : 18
>> 	Date            : 2017-02-24
>>=20
>> Abstract:
>>   RFC 6750 specified the bearer token concept for securing access to
>>   protected resources.  Bearer tokens need to be protected in transit
>>   as well as at rest.  When a client requests access to a protected
>>   resource it hands-over the bearer token to the resource server.
>>=20
>>   The OAuth 2.0 Proof-of-Possession security concept extends bearer
>>   token security and requires the client to demonstrate possession of =
a
>>   key when accessing a protected resource.
>>=20
>>   This document describes how the client obtains this keying material
>>   from the authorization server.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> =
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ =

>>=20
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03
>>=20
>> A diff from the previous version is available at:
>> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-key-distribution-=
03
>>=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
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_B9028F13-8E28-4B8C-ACFD-2FF93119FD79
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

I have been wondering about that myself. Interest seems to =
wained with the TOKBIND work emerging. Maybe I am wrong about that?



Phil

Oracle Corporation, Identity Cloud =
Services & Identity Standards
@independentid
www.independentid.com
phil.hunt@oracle.com










On Feb 24, 2017, at 1:58 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

I updated the =
references but haven't made any other changes.

I had some questions about it so though =
it was worth keeping alive at-least for discussion.

There have been some =
other questions and proposed changes.  

I will take a look through them and see =
if what may be worth updating.

John B.
Begin =
forwarded message:

From: internet-drafts@ietf.org
Subject: [OAUTH-WG] I-D Action: =
draft-ietf-oauth-pop-key-distribution-03.txt
Date: February 24, 2017 at 6:55:25 PM GMT-3
To: <i-d-announce@ietf.org>
Cc: oauth@ietf.org

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

 =
       Title =
          : OAuth 2.0 =
Proof-of-Possession: Authorization Server to Client Key Distribution
        Authors =
        : John Bradley
 =
            &n=
bsp;           &nbs=
p;Phil Hunt
 =
            &n=
bsp;           &nbs=
p;Michael B. Jones
 =
            &n=
bsp;           &nbs=
p;Hannes Tschofenig
	Filename =
       : =
draft-ietf-oauth-pop-key-distribution-03.txt
	Pages =
          : 18
	=
Date =
           : =
2017-02-24

Abstract:
 =
  RFC 6750 specified the bearer token concept for securing =
access to
   protected resources.  Bearer =
tokens need to be protected in transit
   as =
well as at rest.  When a client requests access to a protected
   resource it hands-over the bearer token to the =
resource server.

   The OAuth 2.0 =
Proof-of-Possession security concept extends bearer
 =
  token security and requires the client to demonstrate =
possession of a
   key when accessing a =
protected resource.

   This =
document describes how the client obtains this keying material
   from the authorization server.


The IETF datatracker status page for this =
draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distr=
ibution/

There's also a htmlized =
version available at:
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi=
on-03

A diff from the previous version =
is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-key-di=
stribution-03


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

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

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

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

=

--Apple-Mail=_B9028F13-8E28-4B8C-ACFD-2FF93119FD79--


From nobody Fri Feb 24 15:51:18 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D6F129567 for ; Fri, 24 Feb 2017 15:51:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWyWkkLRAptv for ; Fri, 24 Feb 2017 15:51:14 -0800 (PST)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD26129561 for ; Fri, 24 Feb 2017 15:51:14 -0800 (PST)
Received: by mail-qk0-x229.google.com with SMTP id u188so31765934qkc.2 for ; Fri, 24 Feb 2017 15:51:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qBcKQwEUfjpxCmviGVYj18s3dnlHgxOJPIhFottfjWI=; b=NgMhzxXohD4gpZeS8n1C6zOUxC7L/36uQzZM4sinew2WihuiR0IJZLjDsoOHoOtQwF 0w8N2rboIm2ofD8alCP9SgfMCTmvAyoOANWQPT/MB644FVUHPeofzGkZNYFOfi/LbVak nXG5dgpE6IpRfS1WRMLGDW6+qzq/CjYWCAF/TqQFqsIi9b+qMG8O/GTn9pA6YiLAJRz0 sZEjKGzeN0H9gnXaqV8NpEqQ4VdZIIo7T9LOqEDx/N7lS+s+bTfBKfbIA7EmPqcJmtUh thjN7M8FiJV7YJ6Go57qsvL4h0PuG6QdoT8MQkoxBsUSD1yHdA51I7LcFhra21zYGOMM 45VQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qBcKQwEUfjpxCmviGVYj18s3dnlHgxOJPIhFottfjWI=; b=VsIcdoLx36xWgkKP79p5IVlXsVujN06SAzPXJnn+8U2ZsOjBIdGk4Cf/Sw7cGzyxmt ZZyRQrEso0lzVixgxOmsk5VehRu9czpCBc+1LWcls70sMCKNYCYd5G0PfwMuqwAeW37e sPfbMJRhYdXlbLYNH/3Ndq0EaYOxGT02EPnQnM3im0R63OpCYRoaQNEbd9KCUkO4/Q+B IXY9QKDIJGWLwp1Dkyjf/xa+Tc5t7WhufR/tGCc1r+b1OmdzI93izoRgpFAvhDS8/I15 N+cnclroaPQLGg5wbmJ+PpMNitkdmUGwlnkE79oD8YAdQkid9AnaDZdKBilUmr82S6Qx PXNw==
X-Gm-Message-State: AMke39mfd5opcOdu4mfMw32vLb4DAltQ1cAsnYaHwNI9dUEgZlONGZK3he1yrcjVPD3AxjiP
X-Received: by 10.55.181.6 with SMTP id e6mr5083668qkf.298.1487980273291; Fri, 24 Feb 2017 15:51:13 -0800 (PST)
Received: from [192.168.86.130] ([191.115.25.29]) by smtp.gmail.com with ESMTPSA id x7sm5765706qtc.18.2017.02.24.15.51.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Feb 2017 15:51:12 -0800 (PST)
From: John Bradley 
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Fri, 24 Feb 2017 20:51:09 -0300
In-Reply-To: 
To: Phil Hunt 
References: <148797332573.3278.6515135380852468551.idtracker@ietfa.amsl.com>  
X-Mailer: Apple Mail (2.3259)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c065a00a3121f05494f6788"
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-pop-key-distribution-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Feb 2017 23:51:17 -0000

--94eb2c065a00a3121f05494f6788
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_6691843A-AAE5-4464-B604-67B946654559"


--Apple-Mail=_6691843A-AAE5-4464-B604-67B946654559
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The European banks are interested in mutual TLS for server to server =
connections as part of PSD2/Open Banking.

They have been thinking that they would have central CA and directly use =
CA certificates for all the legs. =20

I sent them this to get them thinking that they could perhaps secure the =
token endpoint with cert based mutual TLS but allow clients to specify =
there own keys for access tokens to make key rotation and deployment =
easier.

I was also think ing that they could protect a jwks_uri with the CA =
certificate using OCSP stapling and then use mutual TLS to the token =
endpoint based on keyid and/or fingerprint. allowing for rotation of =
keys to token endpoint and better support clusters with multiple keys.

I don=E2=80=99t think this has much interest outside of some verticals =
like financials.

John B.
> On Feb 24, 2017, at 8:33 PM, Phil Hunt  wrote:
>=20
> I have been wondering about that myself. Interest seems to wained with =
the TOKBIND work emerging. Maybe I am wrong about that?
>=20
> Phil
>=20
> Oracle Corporation, Identity Cloud Services & Identity Standards
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>=20
>=20
>=20
>=20
>=20
>> On Feb 24, 2017, at 1:58 PM, John Bradley > wrote:
>>=20
>> I updated the references but haven't made any other changes.
>>=20
>> I had some questions about it so though it was worth keeping alive =
at-least for discussion.
>>=20
>> There have been some other questions and proposed changes. =20
>>=20
>> I will take a look through them and see if what may be worth =
updating.
>>=20
>> John B.
>>=20
>>> Begin forwarded message:
>>>=20
>>> From: internet-drafts@ietf.org 
>>> Subject: [OAUTH-WG] I-D Action: =
draft-ietf-oauth-pop-key-distribution-03.txt
>>> Date: February 24, 2017 at 6:55:25 PM GMT-3
>>> To: >
>>> Cc: oauth@ietf.org 
>>>=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 of the =
IETF.
>>>=20
>>>        Title           : OAuth 2.0 Proof-of-Possession: =
Authorization Server to Client Key Distribution
>>>        Authors         : John Bradley
>>>                          Phil Hunt
>>>                          Michael B. Jones
>>>                          Hannes Tschofenig
>>> 	Filename        : draft-ietf-oauth-pop-key-distribution-03.txt
>>> 	Pages           : 18
>>> 	Date            : 2017-02-24
>>>=20
>>> Abstract:
>>>   RFC 6750 specified the bearer token concept for securing access to
>>>   protected resources.  Bearer tokens need to be protected in =
transit
>>>   as well as at rest.  When a client requests access to a protected
>>>   resource it hands-over the bearer token to the resource server.
>>>=20
>>>   The OAuth 2.0 Proof-of-Possession security concept extends bearer
>>>   token security and requires the client to demonstrate possession =
of a
>>>   key when accessing a protected resource.
>>>=20
>>>   This document describes how the client obtains this keying =
material
>>>   from the authorization server.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> =
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distribution/ =

>>>=20
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03 =

>>>=20
>>> A diff from the previous version is available at:
>>> =
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-key-distribution-=
03
>>>=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
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>=20


--Apple-Mail=_6691843A-AAE5-4464-B604-67B946654559
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The European banks are interested in mutual TLS for server to =
server connections as part of PSD2/Open Banking.

They have been thinking that they would =
have central CA and directly use CA certificates for all the legs. =
 

I sent =
them this to get them thinking that they could perhaps secure the token =
endpoint with cert based mutual TLS but allow clients to specify there =
own keys for access tokens to make key rotation and deployment =
easier.

I was =
also think ing that they could protect a jwks_uri with the CA =
certificate using OCSP stapling and then use mutual TLS to the token =
endpoint based on keyid and/or fingerprint. allowing for rotation of =
keys to token endpoint and better support clusters with multiple =
keys.

I =
don=E2=80=99t think this has much interest outside of some verticals =
like financials.

John B.
On Feb 24, 2017, at 8:33 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

I have been =
wondering about that myself. Interest seems to wained with the TOKBIND =
work emerging. Maybe I am wrong about that?



Phil

Oracle Corporation, Identity Cloud =
Services & Identity Standards
@independentid
www.independentid.com
phil.hunt@oracle.com










On Feb 24, 2017, at 1:58 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

I updated the =
references but haven't made any other changes.

I had some questions about it so though =
it was worth keeping alive at-least for discussion.

There have been some =
other questions and proposed changes.  

I will take a look through them and see =
if what may be worth updating.

John B.
Begin =
forwarded message:

From: internet-drafts@ietf.org
Subject: [OAUTH-WG] I-D Action: =
draft-ietf-oauth-pop-key-distribution-03.txt
Date: February 24, 2017 at 6:55:25 PM GMT-3
To: <i-d-announce@ietf.org>
Cc: oauth@ietf.org

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

 =
       Title =
          : OAuth 2.0 =
Proof-of-Possession: Authorization Server to Client Key Distribution
        Authors =
        : John Bradley
 =
            &n=
bsp;           &nbs=
p;Phil Hunt
 =
            &n=
bsp;           &nbs=
p;Michael B. Jones
 =
            &n=
bsp;           &nbs=
p;Hannes Tschofenig
	Filename =
       : =
draft-ietf-oauth-pop-key-distribution-03.txt
	Pages =
          : 18
	=
Date =
           : =
2017-02-24

Abstract:
 =
  RFC 6750 specified the bearer token concept for securing =
access to
   protected resources.  Bearer =
tokens need to be protected in transit
   as =
well as at rest.  When a client requests access to a protected
   resource it hands-over the bearer token to the =
resource server.

   The OAuth 2.0 =
Proof-of-Possession security concept extends bearer
 =
  token security and requires the client to demonstrate =
possession of a
   key when accessing a =
protected resource.

   This =
document describes how the client obtains this keying material
   from the authorization server.


The IETF datatracker status page for this =
draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-pop-key-distr=
ibution/

There's also a htmlized =
version available at:
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi=
on-03

A diff from the previous version =
is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-pop-key-di=
stribution-03


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

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

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

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


=

--Apple-Mail=_6691843A-AAE5-4464-B604-67B946654559--

--94eb2c065a00a3121f05494f6788
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG
A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h
bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy
MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl
ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl
ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1
cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW
pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW
/qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G
sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt
MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G
Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g
JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw
BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1
c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v
b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er
wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y
G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum
NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG
NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2
ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU
MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3
b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX
DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD
VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0
ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng
TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt
Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH
E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA
Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl
ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL
VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6
xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG
A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4
dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5
gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW
t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC
Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0
cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda
e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB
mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2
IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw
MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB
o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM
Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f
a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN
M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR
AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU
Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l
BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9
MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0
L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy
NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB
gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp
ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov
L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3
DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL
5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM
JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N
BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU
jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv
cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y
FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIDm0CTZ1UiwcHhQRyA05bSuRoYLR
7K28LU9ZbZ4Byvx8MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3
MDIyNDIzNTExM1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG
CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl
AwQCATANBgkqhkiG9w0BAQEFAASCAQAuLwKNPhlk0swWjfVIOXMODQnm6Ls0Rr4+hehr+WZokqZo
+SjULDe67YoyQmz4Lau4W/t/n4QxgKJhsKzLY/+w9po/Kwd7hBUGDHAunUC/4CgHQN803c6CtyEN
w5Fb+vkw2KrM3TYL5qWF17Ge2tveG2XtKTcAOEdWtID+Q0EJSNcYmN2+9Ox39eOpGiiFVT6wKVQf
zspI7PzxxFGfwjyHb5kpeJs8IrbFHT+zcocCgeOaIm7eLWjkTaWMmn6uw0yvidwuhoGmbc/rbgIW
/kZrWzZLmsTLzMQIyYG9V6RJjFeQvmTrmnDGG02N7HVbyeRbyvfS+DnQPkgJ9DVVbMJ+
--94eb2c065a00a3121f05494f6788--


From nobody Mon Feb 27 00:22:37 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49683129C46 for ; Mon, 27 Feb 2017 00:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNVgWpmY3BZI for ; Mon, 27 Feb 2017 00:22:34 -0800 (PST)
Received: from MAILOUT11.telekom.de (MAILOUT11.telekom.de [80.149.113.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCB5129C41 for ; Mon, 27 Feb 2017 00:22:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1488183754; x=1519719754; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PGN54ux2xBYZPNtv/XJ64WKAAbGi3XG79gVTsAdcdaw=; b=krSglOtoicpPhZTf8NKWXXGqVqVc/hd2ycpKpSFrCvItzefbQpM0mvxI rJli9Iyg4xAawKzs8U/SrOd8lO82LnuTCotZL2dwyBPlmXm3SadchAQhQ 0TjaMumTa5nocgBSYfw21p0J1XiOQL2I2NPYrupWZBVJgHLgDOtz/ycJ3 /lg9jK1OBXWehGHmcBwBUtWM9borU3Wih2b1ynDd0XXzmg7+IVfX9n8l5 62a7Dg4UJFWagLjFKqK99ZrVDRbrCLEWJT20KSCwLHaLhIzf7agBD6DqX fnF0Hj35b7Lfk4QztIfQt1Lvf4mBN/seDKm3Q1Ta+KI+InfQUG0BTdA7d Q==;
Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT11.telekom.de with ESMTP/TLS/RC4-SHA; 27 Feb 2017 09:22:30 +0100
X-IronPort-AV: E=Sophos;i="5.35,213,1484002800"; d="scan'208";a="626000406"
Received: from he105716.emea1.cds.t-internal.com ([10.169.118.52]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 27 Feb 2017 09:22:29 +0100
Received: from HE105717.EMEA1.cds.t-internal.com (10.169.118.53) by HE105716.emea1.cds.t-internal.com (10.169.118.52) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 27 Feb 2017 09:22:28 +0100
Received: from HE105717.EMEA1.cds.t-internal.com ([fe80::5881:9115:c037:89f8]) by HE105717.emea1.cds.t-internal.com ([fe80::5881:9115:c037:89f8%26]) with mapi id 15.00.1263.000; Mon, 27 Feb 2017 09:22:28 +0100
From: 
To: 
Thread-Topic: [OAUTH-WG] review draft-ietf-oauth-native-apps-07
Thread-Index: AQHSkNKiB+Sg+qOZkkeqpWcByLbJwA==
Date: Mon, 27 Feb 2017 08:22:28 +0000
Message-ID: <4acb6b3e0a724da88aa040f556c01b07@HE105717.emea1.cds.t-internal.com>
References: <0f05922f-ac63-1585-9da1-d54ceda25623@gmx.net>
In-Reply-To: <0f05922f-ac63-1585-9da1-d54ceda25623@gmx.net>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.157.116.207]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: [OAUTH-WG]  review draft-ietf-oauth-native-apps-07
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 08:22:36 -0000

SGkgYWxsLA0KDQpJIGhhdmUgYSBxdWVzdGlvbiB0aGF0IHJlbGF0ZXMgdG8gc2VjdGlvbiBCLjIu
IEFuZHJvaWQgSW1wbGVtZW50YXRpb24gRGV0YWlscy4NCg0KSSB1bmRlcnN0YW5kIHRoaXMgYXMg
YSB3b3JraW5nIGdyb3VwIGJlc3QgcHJhY3RpY2UuIFVuZm9ydHVuYXRlbHkgdGhpcyBkb2VzIG5v
dCBuZWNlc3NhcmlseSBtZWV0IHRoZSBHb29nbGUgaW5zdHJ1Y3Rpb24gZm9yIEFuZHJvaWQuIFRo
ZXJlIGlzIGEgbG90IG9mIGRvY3VtZW50YXRpb24gb3V0IHRoZXJlIHBvaW50aW5nIHRvIHRoZSBB
bmRyb2lkIEFjY291bnQgTWFuYWdlciBhbmQgSSBkbyBub3QgZ2V0IHRoZXNlIGJvdGggdG9nZXRo
ZXIuDQoNCkFueSBpZGVhPw0KDQpCZXN0IFJlZ2FyZHMNCg0KU2ViYXN0aWFuDQoNCi0tIA0KU2Vi
YXN0aWFuwqBFYmxpbmcgLyBzZWJhc3RpYW4uZWJsaW5nQHRlbGVrb20uZGUNCkRldXRzY2hlIFRl
bGVrb20gQUcsIFRlY2hub2xvZ3kgRW5hYmxpbmcgUGxhdGZvcm1zIChQSS1URVApDQoNCg0KDQo=


From nobody Mon Feb 27 00:22:46 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D202129C4E for ; Mon, 27 Feb 2017 00:22:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.82
X-Spam-Level: 
X-Spam-Status: No, score=-3.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEx9diPV0tyL for ; Mon, 27 Feb 2017 00:22:41 -0800 (PST)
Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884E6129C4A for ; Mon, 27 Feb 2017 00:22:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1488183760; x=1519719760; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=/+HnFfcMwCaBBEN1UG6VjWFVxnsDJhn3DMbCjMkZeqI=; b=mF2gFYz7rMUO52O7RA3jYWKMp2x62cMMF7SO50AhitSNgu48sOcYBxa6 rT2zPscqrU9nDCcd9EZbAG8G1O8JNBiKU13iHfqxzEpFJKlIa5510U76E lPpayi3u8nHD5p/hbp7/pf1DeL2edkXj64yIIdPfx6f4PotjzgzVviV3X pvds72j546IpCBmNdREdXcidkjIFa+kU9aZwZPTfRgb3O6ocv5thC7JGy LL/vIWMXYDwGmKM9eTsfWyaIkbm3XdJ3irKkMQEI83/a4GTfMZfy4efnk JRJV3Ue97x9lL+5TxWS1adKYT/NBqYMCeFzNq3+NuwRpxw8O4XVJQ5mVI A==;
Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP/TLS/RC4-SHA; 27 Feb 2017 09:22:36 +0100
X-IronPort-AV: E=Sophos;i="5.35,213,1484002800"; d="scan'208";a="626000458"
Received: from he105717.emea1.cds.t-internal.com ([10.169.118.53]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 27 Feb 2017 09:22:36 +0100
Received: from HE105717.EMEA1.cds.t-internal.com (10.169.118.53) by HE105717.emea1.cds.t-internal.com (10.169.118.53) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 27 Feb 2017 09:22:35 +0100
Received: from HE105717.EMEA1.cds.t-internal.com ([fe80::5881:9115:c037:89f8]) by HE105717.emea1.cds.t-internal.com ([fe80::5881:9115:c037:89f8%26]) with mapi id 15.00.1263.000; Mon, 27 Feb 2017 09:22:35 +0100
From: 
To: 
Thread-Topic: [OAUTH-WG] review draft-ietf-oauth-native-apps-07
Thread-Index: AdKQ0qWv7nDgRO3tSV+lJaE5XGpq1A==
Date: Mon, 27 Feb 2017 08:22:35 +0000
Message-ID: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.157.116.207]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: [OAUTH-WG]  review draft-ietf-oauth-native-apps-07
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 08:22:45 -0000

Hi,

there is a typo in B.4.=20
Search for "are are" and replace it with "are".

Best regards

Sebastian

--=20
Sebastian=A0Ebling / sebastian.ebling@telekom.de / +49 6151 5838207
Deutsche Telekom AG, Technology Enabling Platforms (PI-TEP)


From nobody Mon Feb 27 06:18:05 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3310129FF1 for ; Mon, 27 Feb 2017 06:18:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=manicode-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQd8Y6C-eM9C for ; Mon, 27 Feb 2017 06:18:02 -0800 (PST)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 D0ABA129FEB for ; Mon, 27 Feb 2017 06:18:02 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id d1so24767491ywd.2 for ; Mon, 27 Feb 2017 06:18:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manicode-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=PfpXA7eG7qh9O6fHaqSelNH6W517J9+1SdZFQeUSJks=; b=pqTzycCGaMkP7hLkGkIzdNI2527WOeokJTc+S5AtFQYa+9VckvVRG9qFLygdM47GYW 9KKQRzsTB44oliBeKkrhDRHz9KTP1bU9aY9u0hMMIxDljRERs65w2n5ABT+xfbLn6vL6 o1OaNBk+Pdgu5Fkd3B+ixbVqqS99l+FPzC8WqE6/mOtj4hQCvIG0ChKD1bEZRuWUN7zr PLgv2mXmDJ2VjvcMNkeswWETtdn9GtKNLRVHBizMAj/vA3vTziF11QQW2c4oo8eiBIp9 TP0vvun/9PcAxCgyUHdY48+WIIjkZM04f78aWvt1iTFXcgYL1sI52TBeJf7DEtU2A7QA 4dTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=PfpXA7eG7qh9O6fHaqSelNH6W517J9+1SdZFQeUSJks=; b=h7NUXVtJ0s9MihlX5CDQoYXaJvshIA5ZzAxfACZk49UdPP4IEmFY++UAf9NsccVK1j tMcCnMHT4ZGkIUBXYIzK8dByytJqoXWLB+OlEAgFbkqzARJWGt634RBPoEHb7Nux09Os H5aST9hlYAA7Fka4RPVDCwdgZQZTbEkPgHE4hpjatuE5/yRsS9UgUJ3e+zoAclxq8NvI RrvilibNPTzDhOZZxuPicxD1gheIuF2cXH9N2iN2zUxF4N/WMoYiF9Sdbghs77jG5xPh BkBNPWYu6jjizQ1MeyudPbQg1PEBqo9OUTn/ieIq3JtrgJAdbIpCCovMs6KrHroPAUsE SqPQ==
X-Gm-Message-State: AMke39mw/fUkY9MmOT2xZmKwcDmwcAVB35P+33qtfklwbY7Ded8JpVsyK6bVEgorVcKC2WUE
X-Received: by 10.129.163.65 with SMTP id a62mr13585114ywh.28.1488205081708; Mon, 27 Feb 2017 06:18:01 -0800 (PST)
Received: from [10.95.194.223] ([166.170.52.93]) by smtp.gmail.com with ESMTPSA id h190sm6858282ywf.60.2017.02.27.06.18.00 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 06:18:01 -0800 (PST)
From: Jim Manico 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Mon, 27 Feb 2017 15:17:59 +0100
Message-Id: <3E02AA83-983E-4529-ABE0-6017829AD28E@manicode.com>
To: IETF OAUTH 
X-Mailer: iPhone Mail (14D27)
Archived-At: 
Subject: [OAUTH-WG] SPA applications best practice
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 14:18:04 -0000

I've been collecting opinions about the best OAuth2 workflows for SPA applic=
ations and have come up with the following basic recommendations.

1) The more secure flow is going to be authorization code. Keep access token=
s out of the DOM/Browser history.

2) Implicit flows are your only choice if you allow serverless JS clients to=
 access your OAuth endpoints. This is much easier to implement but carries a=
 great deal more risk. Wether or not this is good for you depends on your th=
reat model and risk tolerance.=20

I'd love to keep going and turn this into a RFC but this is over my head. Do=
es anyone here with more experience care to assist in proposing a SPA-OAuth R=
FC? I'd be happy to help with the grunt work. This is one of the main areas o=
f OAuth where answers are fractured and I'd love to help push more clarity h=
ere.

Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805=


From nobody Mon Feb 27 08:48:01 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D2D129973 for ; Mon, 27 Feb 2017 08:47:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIcwp8WmuejS for ; Mon, 27 Feb 2017 08:47:51 -0800 (PST)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BF31298D0 for ; Mon, 27 Feb 2017 08:47:50 -0800 (PST)
Received: by mail-oi0-x233.google.com with SMTP id 62so41518516oih.2 for ; Mon, 27 Feb 2017 08:47:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nc9j/WKjSurHpO+k4pQdMGBbVacaVFdy9ZmcJglYRus=; b=JUdR/wACjqSWoJ7euwU/Zkr2zBGCcZt8HA/sSedpe+CpwXffYWajZsbz7XbENVK8Pj n4LMPkSIeQUWTkPsEchSNBqqucoxY/Uyp5tcvKBSADqlnmCwGeZcXuqKrDs3VoPZR/8H OIq68D2ACNZxOYu3u83y+2gCCuw/Me+EHpwk/goyuNKyEFq2+sK+LWcIaQazkfJJRTOY cK8XPA3yHjmk/GQcBdjQyVYkzi6KW5DZ1bMU1mFQ4gtOi3/MM2SEiKAoW/RgwfCWigqC 6H7Se+xmzDh6uO2IHLyPF+e6io64L6LkIvwShb2NACiYQ0IM8gWAmtfedUyxSsnNnF5h jvyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nc9j/WKjSurHpO+k4pQdMGBbVacaVFdy9ZmcJglYRus=; b=lU7UcIRe/G0CBaw8/+tgxb93EquXODBEwlkoj84T3dCZAK4uqK4EUXayaB3R1do6Gf i6O53bkh1KgNYv/H0NBJKy1IZtTsmxEo8nrp2n2LpUF83ebWntBXyewCkvFWciQ4UTby OsXaYufaFT9Aoe93MUqYG5CcIWxYjCCl3NquQDrcHjFHVtrvDDa0Fsg/3xJ3aGwQ+MEs SxH1KjVVMAhHfbbwhRjUCNL9i7uQ5vHppVwroxBYyv3uRNH9V9e3bd4QagY2eF2xfA63 lLRPyCzAv1lPf9FXWBCgixfxQNOQmcg4i6GO7F4ZSbBIzsa9wwLKF0QSG5lqRZLZ2GC4 YuPA==
X-Gm-Message-State: AMke39ko9N7/wHHn5Boe2cLFYKCM1+cWvWxDVrLRIUC5nWoj8/a5b766uSKNtkh2JBGmsJ8Oidaq383mYzHynQ==
X-Received: by 10.202.72.10 with SMTP id v10mr526517oia.169.1488214069992; Mon, 27 Feb 2017 08:47:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.125.40 with HTTP; Mon, 27 Feb 2017 08:47:49 -0800 (PST)
In-Reply-To: 
References:   <304c520f-e531-2ac8-f93f-b91aae11253c@free.fr>  
From: Samuel Erdtman 
Date: Mon, 27 Feb 2017 17:47:49 +0100
Message-ID: 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=001a113dc6aafdf898054985d62b
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] review draft-ietf-oauth-native-apps-07
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 16:47:53 -0000

--001a113dc6aafdf898054985d62b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the replies.

If there are no formal guidelines from IETF I think we should just proceed
it is a good and informative spec, it was just to me it felt slightly of.

Based on the conversation I have no objections taking this draft to RFC.

//Samuel

On Wed, Feb 22, 2017 at 12:09 AM, Justin Richer  wrote:

> When I brought RFCs 7591, 7592, and 7662 up through the finalization
> process, I learned that there are two camps out there on normative
> requirements in the security considerations section. Some like them, as
> long as they don=E2=80=99t contradict requirements/advice in previous sec=
tions, and
> some don=E2=80=99t like them, preferring all normative material be in the=
 =E2=80=9Cbody=E2=80=9D of
> the spec itself. I was given the impression that it was more of a stylist=
ic
> choice than anything, but I can only speak from my personal experience.
>
>  =E2=80=94 Justin
>
> On Feb 21, 2017, at 3:17 PM, William Denniss  wrote:
>
> The only real requirement in that section I guess is the use of PKCE
> (8.2).  That requirement could be moved to the body of the doc, while
> keeping the longer discussing around code interception in the security
> considerations.  To me the remaining text are indeed security best
> practices / clarifications.
>
> Other OAuth WG RFCs have requirement level capitalization in the Security
> Section like RFC7591. I always assumed these were best-practice security
> requirements. But if the style is really not to do this, the requirement
> level capitalization could be dropped from that section in the native app=
s
> BCP.
>
> On Tue, Feb 21, 2017 at 12:50 AM, Denis  wrote:
>
>>
>> I *don't thin**k* it's normal to have normative text in the Security
>> Considerations, hence I support Samuel's position.
>>
>> Let us look at the first MUST from RFC 6749 in the Security
>> Considerations section:
>>
>>    The authorization server *MUST *authenticate the client *whenever pos=
sible*.
>> This sentence is incorrect. The right sentence should be :
>>
>>    The authorization server *should *authenticate the client whenever po=
ssible.
>>
>> RFC 6749 is not an example to follow.
>>
>> Denis
>>
>>
>> I do think it's normal to have normative text in the Security
>> Considerations.  RFC6749 has a lengthy Security Considerations section
>>  with a lot of normative
>> text.
>>
>> Think of it this way: Sections 4 to 7 describe how to use native app URI
>> schemes to perform OAuth flows from the app to browser and back. If you
>> only read those sections, you could have a functioning (but potentially
>> insecure) OAuth flow in a native app. The security section adds some
>> security requirements and clarifications for implementing Sections 4-7,
>> like using PKCE, and more.
>>
>> Reviewing sub-section by sub-section:
>>
>> 8.1 Definitely belongs here, as the the whole BCP is about native-app UR=
I
>> schemes, whereas doing OAuth in a WebView doesn't need those (as the cli=
ent
>> can just pluck out the code from any redirect URI)
>> 8.2 Requires that servers who want to follow the native apps BCP support
>> PKCE, and recommends that they reject requests from clients who don't.
>> This *could* be in the main doc, but since PKCE is an existing thing, an=
d
>> is purely additive from a security perspective, I think this reference
>> works fine. Originally I talked about PKCE more in the doc body, but som=
e
>> reviewers thought it was then a little duplicative of the PKCE doc itsel=
f.
>> 8.3 This reads like classic security considerations to me, clarifying
>> some details of 7.3
>> 8.4 Part of this reads a little new-ish, regarding distinguishing native
>> clients from web ones. But on review, I think could just be re-worded to
>> reference RFC6749 Section 2.1.
>> 8.5 This one belongs where it is since the body of the BCP is talking
>> about the code flow.
>> 8.6 Totally belongs.
>> 8.7 to 8.11 belong IMO, they are security clarifications of long-standin=
g
>> topics.
>>
>> My methodology when reviewing this was: is the text introducing a new
>> topic directly related to native apps or sections 4-7, or does it discus=
s
>> an old security topic in the context of native apps, or add security
>> related discussions of the content in 4-7. Of all those, I really only s=
ee
>> a bit of new topic related to native apps in 8.4, and in actual fact it
>> that sub-section should probably be reworded since RFC6749 already
>> establishes the public client type, which native apps are and a referenc=
e
>> would be more appropriate (which would reduce it to just clarifying an o=
ld
>> topic).
>>
>> What do you think of this analysis? Do you have any specific sections or
>> text you feel are better suited in the document body?  I will take an
>> action item to revise section 8.4.
>>
>> On Mon, Feb 20, 2017 at 9:57 PM, Samuel Erdtman 
>> wrote:
>>
>>> Hi,
>>>
>>> I just had a question on best practice. In this document a large part o=
f
>>> the normative text is located under Security Considerations.
>>>
>>> I had previously seen Security Considerations as things to think about
>>> when implementing not so much as MUSTs and MUST NOTs.
>>>
>>> I think it is okay to have it this way but it surprised me a bit and
>>> wanted to ask if there is any best practice for the Security Considerat=
ions
>>> section saying what type of information it should include.
>>>
>>> Best Regards
>>> Samuel Erdtman
>>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa=
uth
>>
>>
>>
>> _______________________________________________
>> 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
>
>

--001a113dc6aafdf898054985d62b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks for the replies.

If the=
re are no formal guidelines from IETF I think we should just proceed it is =
a good and informative spec, it was just to me it felt slightly of.

=

Based on the conversation I have no objections taking this draft to R=
FC.

//Samuel
On Wed, Feb 22, 2017 at 12:09 AM, Justin Riche=
r <jricher@mit.edu> wrote:
<=
div style=3D"word-wrap:break-word">When I brought RFCs 7591, 7592, and 7662=
 up through the finalization process, I learned that there are two camps ou=
t there on normative requirements in the security considerations section. S=
ome like them, as long as they don=E2=80=99t contradict requirements/advice=
 in previous sections, and some don=E2=80=99t like them, preferring all nor=
mative material be in the =E2=80=9Cbody=E2=80=9D of the spec itself. I was =
given the impression that it was more of a stylistic choice than anything, =
but I can only speak from my personal experience.

=C2=A0=E2=80=94 Justin

On Feb 21, 2017, at 3:17 PM, William Denniss <wdenniss@google.com> wrote:
The only real requirement in that section I guess is the use of =
PKCE (8.2).=C2=A0 That requirement could be moved to the body of the doc, w=
hile keeping the longer discussing around code interception in the security=
 considerations.=C2=A0 To me the remaining text are indeed security best pr=
actices / clarifications.

Other OAuth WG RFCs have=
 requirement level capitalization in the Security Section like=C2=A0RFC7591=
. I always assumed these were best-practice security requirements. But if t=
he style is really not to do this, the requirement level capitalization cou=
ld be dropped from that section in the native apps BCP.

On Tue, Feb 21, 2017=
 at 12:50 AM, Denis <denis.ietf@free.fr> wrote:

 =20
   =20
 =20
  

    


      I don't think it's normal to have normative tex=
t in
      the Security Considerations, hence I support Samuel's position.
      

      Let us look at the first MUST from RFC 6749 in the Security
      Considerations section:
      
   The authorization server MUST aut=
henticate the client whenever possible.

This sentence is incorrect. The right sentence should =
be :

   The authorization server should authenticate the client whenever =
possible.

RFC 6749 is not an example to follow.

Denis=20


      

    

    

      
I do think it's normal to have normative text in
        the Security Considerations.=C2=A0 RFC6749 has a lengthy Security
          Considerations section with a lot of normative text.
        


        

        
Think of it this way: Sections 4 to 7 describe how to use
          native app URI schemes to perform OAuth flows from the app to
          browser and back. If you only read those sections, you could
          have a functioning (but potentially insecure) OAuth flow in a
          native app. The security section adds some security
          requirements and clarifications for implementing Sections 4-7,
          like using PKCE, and more.

        


        

        
Reviewing sub-section by sub-section:

        


        

        
8.1 Definitely belongs here, as the the whole BCP is about
          native-app URI schemes, whereas doing OAuth in a WebView
          doesn't need those (as the client can just pluck out the code
          from any redirect URI)

        
8.2 Requires that servers who want to follow the native
          apps BCP support PKCE, and recommends that they reject
          requests from clients who don't.=C2=A0 This *could* be in the=
 main
          doc, but since PKCE is an existing thing, and is purely
          additive from a security perspective, I think this reference
          works fine. Originally I talked about PKCE more in the doc
          body, but some reviewers thought it was then a little
          duplicative of the PKCE doc itself.

        
8.3 This reads like classic security considerations to me,
          clarifying some details of 7.3

        
8.4 Part of this reads a little new-ish, regarding
          distinguishing native clients from web ones. But on review, I
          think could just be re-worded to reference RFC6749 Section
          2.1.

        
8.5 This one belongs where it is since the body of the BCP
          is talking about the code flow.

        
8.6 Totally belongs.

        
8.7 to 8.11 belong IMO, they are security clarifications of
          long-standing topics.=C2=A0

        


        

        
My methodology when reviewing this was: is the text
          introducing a new topic directly related to native apps or
          sections 4-7, or does it discuss an old security topic in the
          context of native apps, or add security related discussions of
          the content in 4-7. Of all those, I really only see a bit of
          new topic related to native apps in 8.4, and in actual fact it
          that sub-section should probably be reworded since RFC6749
          already establishes the public client type, which native apps
          are and a reference would be more appropriate (which would
          reduce it to just clarifying an old topic).

        


        

        
What do you think of this analysis? Do you have any
          specific sections or text you feel are better suited in the
          document body?=C2=A0 I will take an action item to revise section
          8.4.

      

      


        
On Mon, Feb 20, 2017 at 9:57 PM, Samuel
          Erdtman <samuel@erdtman.se>
          wrote:

          

            

              

                

                  
Hi,

                    

                  

                  I just had a question on best practice. In this
                  document a large part of the normative text is located
                  under Security Considerations.

                

                

                I had previously seen Security Considerations as things
                to think about when implementing not so much as MUSTs
                and MUST NOTs.

                

              

              I think it is okay to have it this way but it surprised me
              a bit and wanted to ask if there is any best practice for
              the Security Considerations section saying what type of
              information it should include.

              


              

              
Best Regards<=
br>
                  

              
                  
Samuel Erdtman

                  

                

          

        

        

      

      

      

      

      
_______________________________________________
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<=
br>OAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth


_______________________________=
________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





--001a113dc6aafdf898054985d62b--


From nobody Mon Feb 27 09:46:22 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0E512A297; Mon, 27 Feb 2017 09:46:20 -0800 (PST)
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.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148821758095.21176.8129728266233946666.idtracker@ietfa.amsl.com>
Date: Mon, 27 Feb 2017 09:46:20 -0800
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-04.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 17:46:21 -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 of the IETF.

        Title           : OAuth 2.0 Device Flow for Browserless and Input Constrained Devices
        Authors         : William Denniss
                          John Bradley
                          Michael B. Jones
                          Hannes Tschofenig
	Filename        : draft-ietf-oauth-device-flow-04.txt
	Pages           : 15
	Date            : 2017-02-27

Abstract:
   This OAuth 2.0 authorization flow for browserless and input
   constrained devices, often referred to as the device flow, enables
   OAuth clients to request user authorization from devices that have an
   Internet connection, but don't have an easy input method (such as a
   smart TV, media console, picture frame, or printer), or lack a
   suitable browser for a more traditional OAuth flow.  This
   authorization flow instructs the user to perform the authorization
   request on a secondary device, such as a smartphone.  There is no
   requirement for communication between the constrained device and the
   user's secondary device.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04

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


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

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


From nobody Mon Feb 27 10:14:58 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1857A12A2BD for ; Mon, 27 Feb 2017 10:14:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level: 
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaFdyJXtAW59 for ; Mon, 27 Feb 2017 10:14:54 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 36C8F12999C for ; Mon, 27 Feb 2017 10:14:54 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id u188so110150408qkc.2 for ; Mon, 27 Feb 2017 10:14:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xg70TQZdepKhrXpAA6ZdbTAJ12N8sktNH1y3j3TxkgI=; b=lvi9E9AbpJ4VN4/avhUlSBh/k2Ysp5EUbj/y5CYUikWRhFfYAZ8d8DfKlV5xUUjNEf XL5p17cEGymVK3oilZbtwNA/HiHFfh9ILr6JYoxjLl8ZjA9+loAnmrXe8Rnyd0zdo2OK IdlpaMGitl+py/vRRbxbOEp2fY0DzsOzp58ycADo5MPkDE2s+8qmWYqe53x5SPva4Oqm /eRc2Qn+TtM/dNozzO/J8oCadG+wlwIH7RirdZz6SHAe43hVv8jIsFfCanHhqGZC6n5s RKxol+BWfWScjlADISKIaIgUcJWswVrJDRefmnfxoGp0xhQ+ZGlfKpSNE1Km09PcUHqe pXQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xg70TQZdepKhrXpAA6ZdbTAJ12N8sktNH1y3j3TxkgI=; b=bcgUC5PEYjwaYUM+OTs4nuVCgCeTwL1ja2ehJhKTl7wWDlY8N9af8a0pSuhPvZOAsx Pxdd2j4vTMH6PATerV4xUtIe7/lvvcWUCxu4NWZUB3xlfkHy7+k7KBKEAKJ7jQX/wTCm H/xq7ocxQIi8jv2bcVtVwSN58S9ri/jzBVFsYgWpleD6CDTfu6e8Ff2ETgMmmT0pHh/s 98xi4zclzyLlqZT7FV/KE9igARbhPLRHEh681Vsl1m9avVScGnuRaZOJmOTZEZkx6DDL R95zbx9zeIKCYeRrwNv8K8+/WhBjnT8Evou7swRwnsGD7yP7xpZS9+tqjeg8O4b33BeZ uNZQ==
X-Gm-Message-State: AMke39kT3PvIKuhGOItk6xui028S1dV9IiySNHwEXDLWQDI+EhXDUfwhaekKf1sJh3fPl538Eh6SjeYm4cJ6yHbq
X-Received: by 10.200.35.36 with SMTP id a33mr15734430qta.216.1488219293017; Mon, 27 Feb 2017 10:14:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.36.203 with HTTP; Mon, 27 Feb 2017 10:14:32 -0800 (PST)
In-Reply-To: <148821758095.21176.8129728266233946666.idtracker@ietfa.amsl.com>
References: <148821758095.21176.8129728266233946666.idtracker@ietfa.amsl.com>
From: William Denniss 
Date: Mon, 27 Feb 2017 10:14:32 -0800
Message-ID: 
To: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113a7db84f4d8c0549870e8e
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-04.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Feb 2017 18:14:56 -0000

--001a113a7db84f4d8c0549870e8e
Content-Type: text/plain; charset=UTF-8

My coauthors and I posted draft 04 of the OAuth 2.0 Device Flow for
Browserless and Input Constrained Devices draft today.

Key changes:

   1. Title updated to reflect specificity of devices that use this flow.
   2. User interaction section expanded.
   3. OAuth 2.0 Metadata
    for the device
   authorization endpoint added.
   4. User interaction section expanded.
   5. Security Considerations section added.
   6. Usability Considerations section added.

Please give it a look!

On Mon, Feb 27, 2017 at 9:46 AM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol of the IETF.
>
>         Title           : OAuth 2.0 Device Flow for Browserless and Input
> Constrained Devices
>         Authors         : William Denniss
>                           John Bradley
>                           Michael B. Jones
>                           Hannes Tschofenig
>         Filename        : draft-ietf-oauth-device-flow-04.txt
>         Pages           : 15
>         Date            : 2017-02-27
>
> Abstract:
>    This OAuth 2.0 authorization flow for browserless and input
>    constrained devices, often referred to as the device flow, enables
>    OAuth clients to request user authorization from devices that have an
>    Internet connection, but don't have an easy input method (such as a
>    smart TV, media console, picture frame, or printer), or lack a
>    suitable browser for a more traditional OAuth flow.  This
>    authorization flow instructs the user to perform the authorization
>    request on a secondary device, such as a smartphone.  There is no
>    requirement for communication between the constrained device and the
>    user's secondary device.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001a113a7db84f4d8c0549870e8e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


My coauthors and I posted draft 04 of the OAuth 2.0 D=
evice Flow for Browserless and Input Constrained Devices draft today.
=


Key changes:
  1. Title updated to reflect specificit=
y of devices that use this flow.
  2. User interaction section expanded.=

  3. OAuth 2.0 Metadata for the device authorization endpoint added.
  4. User interaction section expanded.
  5. Security Considerations se=
ction added.
  6. Usability Considerations section added.
<=
/div>
Please give it a look!

On Mon, Feb 27, 2017 at 9:4=
6 AM,  <internet-drafts@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Web Authorization Protocol of the IETF.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 OAuth 2.0 Device Flow for Browserless and Input Constrained Devices

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Will=
iam Denniss

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 John Bradley

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Michael B. Jones

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 Hannes Tschofenig

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-device-flow-04.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 15

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2017-02-27



Abstract:

=C2=A0 =C2=A0This OAuth 2.0 authorization flow for browserless and input
=C2=A0 =C2=A0constrained devices, often referred to as the device flow, ena=
bles

=C2=A0 =C2=A0OAuth clients to request user authorization from devices that =
have an

=C2=A0 =C2=A0Internet connection, but don't have an easy input method (=
such as a

=C2=A0 =C2=A0smart TV, media console, picture frame, or printer), or lack a=


=C2=A0 =C2=A0suitable browser for a more traditional OAuth flow.=C2=A0 This=


=C2=A0 =C2=A0authorization flow instructs the user to perform the authoriza=
tion

=C2=A0 =C2=A0request on a secondary device, such as a smartphone.=C2=A0 The=
re is no

=C2=A0 =C2=A0requirement for communication between the constrained device a=
nd the

=C2=A0 =C2=A0user's secondary device.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/=
draft-ietf-oauth-device-flow/



There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ie=
tf-oauth-device-flow-04



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-device-flow-04





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





--001a113a7db84f4d8c0549870e8e--


From nobody Mon Feb 27 21:56:29 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA96312941E for ; Mon, 27 Feb 2017 21:56:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehrY59QkrwKE for ; Mon, 27 Feb 2017 21:56:26 -0800 (PST)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D831294CD for ; Mon, 27 Feb 2017 21:56:25 -0800 (PST)
Received: by mail-oi0-x22a.google.com with SMTP id 2so1126614oif.0 for ; Mon, 27 Feb 2017 21:56:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eX91t2wMOkxlLIkQhDp2n5y4lVHGn2A6KW9mN3g6AMM=; b=kVpVyc+q0lHg76svVpZziC7K2Ly/CzWK40s9NBIr45P8cZRL3SCfmWB+HswqpP3ZNB OJ8Tbd1kruuUeA1J4j836LyaWb50v0wHzXuXNgioTx202H0ewqP7ZHxAPijciVJ5Hw6K IVJGsXkJfg7pLJUKFUezKEnDMc3rbvUF1Wnq4VGxiibRc8IfoYPag0peqHYpqe3FVgkT 6JImAYYEWLHpT2h4/JFDQQFftBIEIl616r2dGzW0PBi6TBgjrT5HNzuHnhCdguF/OMTA 5uRdOh13G/xHrvrKJWnTaydyyDIvOzmdQvwURKhBRBcQ8Os1VHR5WlHZ+lUt+KgoL4tX lEGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eX91t2wMOkxlLIkQhDp2n5y4lVHGn2A6KW9mN3g6AMM=; b=gHAX+9zMy5sVWsf/l2DbsRLJ9ugdH+ydHb+D42O7xx5aPsdz3JN1itMj5PTDtMvzdj 3D+MJhri6+4EsX/bFIpmEp+dUBGVvaPzd8IghF+KsRJdBSqMsVgymGlSAP03Y5/8t39Q 3uU/Eg3hk3l/qwT+o9sWdxJhwnR+gZB8fP+iWcgRoJvkfrad+PVJY4cQvhKkoQHUebxr qQZH7EIlOre3jhbvN32VxS9POIo03XqEeUPp0sbNPytapebdFdDXU0pFrncMJjLyW0hP GyBveqDhiXUWHS+ECfkZeC1/Zg96Gm/6KGOQToGfZ9zdHkLbyGpFpLaE8ZqrOdben5+B Rp+A==
X-Gm-Message-State: AMke39nc10pP7t6ZXRpJZpMZBIjrrT5KrjB8QHXT01JfTp0hHFLOO5imyyDUjKWGnKG4ATp+TaUZPRyCMkPhgA==
X-Received: by 10.202.7.68 with SMTP id 65mr313939oih.34.1488261384949; Mon, 27 Feb 2017 21:56:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.125.40 with HTTP; Mon, 27 Feb 2017 21:56:24 -0800 (PST)
In-Reply-To: <3E02AA83-983E-4529-ABE0-6017829AD28E@manicode.com>
References: <3E02AA83-983E-4529-ABE0-6017829AD28E@manicode.com>
From: Samuel Erdtman 
Date: Tue, 28 Feb 2017 06:56:24 +0100
Message-ID: 
To: Jim Manico 
Content-Type: multipart/alternative; boundary=94eb2c13f2482ee5ad054990db3b
Archived-At: 
Cc: IETF OAUTH 
Subject: Re: [OAUTH-WG] SPA applications best practice
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2017 05:56:28 -0000

--94eb2c13f2482ee5ad054990db3b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Jim,

If there is enough information I think such RFC could be interesting in the
same way as  "OAuth 2.0 for Native Apps" (
https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07) is for native
app.

To see if the group also thinks so I would suggest to create a personal
draft and ask it to be adopted as a working group item. (I=C2=B4ll send you=
 a
direct message with some details on how to do that)

Best Regards
Samuel Erdtman


On Mon, Feb 27, 2017 at 3:17 PM, Jim Manico  wrote:

> I've been collecting opinions about the best OAuth2 workflows for SPA
> applications and have come up with the following basic recommendations.
>
> 1) The more secure flow is going to be authorization code. Keep access
> tokens out of the DOM/Browser history.
>
> 2) Implicit flows are your only choice if you allow serverless JS clients
> to access your OAuth endpoints. This is much easier to implement but
> carries a great deal more risk. Wether or not this is good for you depend=
s
> on your threat model and risk tolerance.
>
> I'd love to keep going and turn this into a RFC but this is over my head.
> Does anyone here with more experience care to assist in proposing a
> SPA-OAuth RFC? I'd be happy to help with the grunt work. This is one of t=
he
> main areas of OAuth where answers are fractured and I'd love to help push
> more clarity here.
>
> Aloha,
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--94eb2c13f2482ee5ad054990db3b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Jim,

If there is enough informat=
ion I think such RFC could be interesting in the same way as=C2=A0 "OA=
uth 2.0 for Native Apps" (https://tools.ietf.org/html/draft-ietf-oauth-na=
tive-apps-07) is for native app.

To see if the group =
also thinks so I would suggest to create a personal draft and ask it to be =
adopted as a working group item. (I=C2=B4ll send you a direct message with =
some details on how to do that)

Best Regards
Sam=
uel Erdtman

 
=

On Mon, Feb 27, 2017 at 3:17 PM, Jim Manico =
<jim@manicode.com> wrote:
I=
've been collecting opinions about the best OAuth2 workflows for SPA ap=
plications and have come up with the following basic recommendations.



1) The more secure flow is going to be authorization code. Keep access toke=
ns out of the DOM/Browser history.



2) Implicit flows are your only choice if you allow serverless JS clients t=
o access your OAuth endpoints. This is much easier to implement but carries=
 a great deal more risk. Wether or not this is good for you depends on your=
 threat model and risk tolerance.



I'd love to keep going and turn this into a RFC but this is over my hea=
d. Does anyone here with more experience care to assist in proposing a SPA-=
OAuth RFC? I'd be happy to help with the grunt work. This is one of the=
 main areas of OAuth where answers are fractured and I'd love to help p=
ush more clarity here.



Aloha,

--

Jim Manico

@Manicode

Secure Coding Education

+1 (808)=
 652-3805

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





--94eb2c13f2482ee5ad054990db3b--


From nobody Tue Feb 28 12:51:17 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B087B1296CD for ; Tue, 28 Feb 2017 12:51:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQYPoUzP08FT for ; Tue, 28 Feb 2017 12:51:14 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 667E41296FF for ; Tue, 28 Feb 2017 12:51:04 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id l138so17580189ywc.0 for ; Tue, 28 Feb 2017 12:51:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0SywE067eQTJ34W2EDfgNlKfCyyFOLPCYfODEgkW6oQ=; b=WovTJinrOZu/RCi19DaRDftvbXX4SsKL5Dc6YruM0YDi36RJa+y0p1Zq3zMghFBMZr TG8WWPga92rco4s4NEacvA+lrl6iJ7TAMrOPqOTPJxoEZnebEfPs4ekJc72CjsCV5EM7 apXlDhXG1jBB8h0mAMotvykz2D11e313dJUSc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0SywE067eQTJ34W2EDfgNlKfCyyFOLPCYfODEgkW6oQ=; b=T+RYLBTmY//EfXMOGam5/a+qYwzV+2ebwXsG8rQ1KwmQr3nM8SZdBLvp2iVtbvnQ1Y aWn/W+EI06a5dUarwUPAsXB9KxYnRkZxwucaOMcm/ITV89WfM06ZFhNppbZXdiT+GojG EV3tUbazH1vEsHo7oMxYlc1IzyLaFSHnx9JyeskLbzP3TSQCggFOsH2b0QKHsy7pE9dG YAnlWfnHSw1GBkSq9jeBjh49/5FiycZwUr42cOzSgrCuISlZS81ATeIs8X9EurP5Yrxk yZg2hHgmk9yKqFVxrrYVd1AOgkR4czy0hv8ZSgeBHfgodLkhna/f81AE/HAtX4GM8Xlq YCGQ==
X-Gm-Message-State: AMke39nE+GutND/JmJXzqXZfiKzeSgSqoHiHwgWRCpnf9xNnwpeBPSuqJLYstl06p7s/AxLrdxOnHrtdyJVW18i/
X-Received: by 10.129.98.70 with SMTP id w67mr1470969ywb.184.1488315063484; Tue, 28 Feb 2017 12:51:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.43.4 with HTTP; Tue, 28 Feb 2017 12:51:02 -0800 (PST)
Received: by 10.37.43.4 with HTTP; Tue, 28 Feb 2017 12:51:02 -0800 (PST)
In-Reply-To: <0f05922f-ac63-1585-9da1-d54ceda25623@gmx.net>
References: <0f05922f-ac63-1585-9da1-d54ceda25623@gmx.net>
From: Brian Campbell 
Date: Tue, 28 Feb 2017 13:51:02 -0700
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a11471baeac9a3a05499d5aec
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] Pushing "OAuth 2.0 for Native Apps" to the IESG -- Short Working Group Last Call
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2017 20:51:15 -0000

--001a11471baeac9a3a05499d5aec
Content-Type: text/plain; charset=UTF-8

-07 LGTM

On Feb 20, 2017 2:53 AM, "Hannes Tschofenig" 
wrote:

> Hi all,
>
> after the working group last call of the "OAuth 2.0 for Native Apps"
> document July last year (see
> https://www.ietf.org/mail-archive/web/oauth/current/msg16534.html) I
> had, as a shepherd, collected IPR confirmations (see
> https://www.ietf.org/mail-archive/web/oauth/current/msg16672.html) and
> produced a shepherd writeup (see
> https://www.ietf.org/mail-archive/web/oauth/current/msg16702.html).
>
> Since version -03 and the current version -07 a fair amount of text has
> been changed, see
> https://tools.ietf.org/rfcdiff?url1=https://tools.
> ietf.org/id/draft-ietf-oauth-native-apps-03.txt&url2=https:
> //tools.ietf.org/id/draft-ietf-oauth-native-apps-07.txt
>
> Although most of those changes are editorial and normative changes have
> been discussed on the mailing list I believe it is fair to let the group
> take a brief look at the final version.
>
> For this reason we will issue a short, one week, working group last call
> before pushing the document to the IESG.
>
> So, please provide your comments to the list no later than February 27th.
>
> Here is the link to the document again:
> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07
>
> Ciao
> Hannes & Derek
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a11471baeac9a3a05499d5aec
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


-07 LGTM

On Feb 20, 2017 2:53 AM, "Hannes Tschofenig" <=
;hannes.tsch=
ofenig@gmx.net> wrote:
Hi all,



after the working group last call of the "OAuth 2.0 for Native Apps&qu=
ot;

document July last year (see

https://www.ietf.org/mail-arch=
ive/web/oauth/current/msg16534.html) I

had, as a shepherd, collected IPR confirmations (see

https://www.ietf.org/mail-arch=
ive/web/oauth/current/msg16672.html) and

produced a shepherd writeup (see

https://www.ietf.org/mail-arch=
ive/web/oauth/current/msg16702.html).



Since version -03 and the current version -07 a fair amount of text has

been changed, see

htt=
ps://tools.ietf.org/rfcdiff?url1=3Dhttps://tools.ietf.org/id/draf=
t-ietf-oauth-native-apps-03.txt&url2=3Dhttps://tools.ietf.org=
/id/draft-ietf-oauth-native-apps-07.txt



Although most of those changes are editorial and normative changes have

been discussed on the mailing list I believe it is fair to let the group
take a brief look at the final version.



For this reason we will issue a short, one week, working group last call
before pushing the document to the IESG.



So, please provide your comments to the list no later than February 27th.


Here is the link to the document again:

https://tools.ietf.org/html/draft-ie=
tf-oauth-native-apps-07



Ciao

Hannes & Derek




_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth




--001a11471baeac9a3a05499d5aec--


From nobody Tue Feb 28 14:23:42 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2DF128AC9 for ; Tue, 28 Feb 2017 14:23:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsFi3_4UnZl5 for ; Tue, 28 Feb 2017 14:23:39 -0800 (PST)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::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 4C7DD1293E0 for ; Tue, 28 Feb 2017 14:23:39 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id v200so19131569ywc.3 for ; Tue, 28 Feb 2017 14:23:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jZdjscVWi0yV5TkfaQBEUDtoJXdaKmLMYOhKnh8Zpdk=; b=OF2/mvSZDpBLkhQlOgKkDYPdPZgVw7k82Sq/BClsNOzSTqD6CWwcsRdTCrgFiJALS5 0HopeaNvrSrvJ3hBGGFn4Fa9gTOZ+j5KjLKaJ7ZrCQGFmoDvs2W0eW4of9ADkW9lZQ/G ij5fmOOheDTPHXzOh6MCTZrBYbQwd+bVDtdXA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jZdjscVWi0yV5TkfaQBEUDtoJXdaKmLMYOhKnh8Zpdk=; b=eK/CnkoxXFIDDwil3rNRymzGSOfWDjT6Q9zMVjte0wKszoFhy3gj3wvrhUYg5+98CF m9R6HbtlrQPrGIg6OD/lc59LPKCWRpvDrAE5VODTt+XxbKdlyytQ7PevAq84pC/avisM 3h1J08J9ZGXJlQJA7hS+8TGXbkLappJjhoglqGoab9rI3LenPwC8fR7FeX2YX4a4Ew+D 2c/PDLaVU34zljW01vEiYIZZdJxtNRfo2GdDjbz1KK252yfsraPtdSk075n7V5xX6SLj 6qzPTSMb5BOe1s7tJCgEod3+f+Py3lbOkBM0G1yY2bWv6Nmx21BQDOOTbc0gmpTOSboy tJ9Q==
X-Gm-Message-State: AMke39kkG0I5e+8XnY6sBWuH1Df4RdT0jdBMHW7rcwlmZ4yD8yyaox5Z5hm7DZjK+W9//XS12FuQl5WbUdaxctlL
X-Received: by 10.37.163.38 with SMTP id d35mr1570653ybi.32.1488320618366; Tue, 28 Feb 2017 14:23:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.43.4 with HTTP; Tue, 28 Feb 2017 14:23:07 -0800 (PST)
In-Reply-To: 
References: 
From: Brian Campbell 
Date: Tue, 28 Feb 2017 15:23:07 -0700
Message-ID: 
To: Jan Brennenstuhl 
Content-Type: multipart/alternative; boundary=94eb2c19a52cc573fa05499ea533
Archived-At: 
Cc: oauth 
Subject: Re: [OAUTH-WG] [oauth-token-exchange] Composite Token Design
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Feb 2017 22:23:41 -0000

--94eb2c19a52cc573fa05499ea533
Content-Type: text/plain; charset=UTF-8

Hi Jan,

I don't think you're missing anything. However, the use of the 'act' claim
to identify the delegate and convey that delegation is happening was an
intentional decision. While delegation is a security sensitive thing, it
often occurs as impersonation with no explicit indication about delegation.
Layering on the delegate info in a claim like this allows for those kinds
of cases to continue working while augmenting the token with data
about the delegate
that can be used for audit or access control (but doesn't have to be).
Which, I guess, is to say that your worries were indeed a design goal of
the document. That may not alleviate those worries but hopefully does
provide some insight into the reasoning behind the current composite token
approach.



On Thu, Feb 23, 2017 at 7:46 AM, Jan Brennenstuhl <
jan.brennenstuhl@zalando.de> wrote:

> Hey everyone,
>
> Let me shortly introduce myself - My name is Jan, I do IAM at Zalando SE.
>
> I am writing, because I like to get a better understanding of the
> reasoning behind a fundamental conceptual decision that was made in the
> oauth-token-exchange draft.
>
> The draft describes one possible design of a composite token: an 'act'
> claim in a representee token, meaning that a regular principal token gives
> the information about a possible delegate/ agent a piggyback.
>
> In my eyes, this is not quite intuitive nor the most secure solution as:
>
>
>    - the current approach cloaks the true nature of the delegation as the
>    actual actor is not represented by/ in the primary token,
>    - the current approach would be entirely transparent for old/ legacy
>    systems which do not know about a possible act claim. Those applications,
>    would support delegation simply because they do not know any better. For
>    them, the intended delegation would look like a true impersonation.
>
>
> As delegation usually is a highly security sensitive thing to do, I
> personally would prefer the probably more secure approach of defining a
> primary agent token with a nested representee token/ information. This
> would lead to systems not just silently supporting delegation (without
> knowing about it). They would need to explicitly support the spec if they
> want to support delegation.
>
> My questions now are:
>
>    - am I missing something here,
>    - do you share my worries,
>    - what are the actual reasons for the current composite token design?
>
>
> Would be great if you could provide some background info on why you chose
> to follow the current approach.
>
> Thanks, Jan
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--94eb2c19a52cc573fa05499ea533
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Jan,

I don't think you&=
#39;re missing anything. However, the use of the 'act' claim to  id=
entify the delegate and convey that delegation is happening was an intentio=
nal decision. While delegation is a security=
 sensitive thing, it often occurs as impersonation with no explicit indicat=
ion about delegation. Layering on the=
 delegate info in a claim like this allows for those kinds of cases =
to continue working while augmenting the token with data about the delegate that can be used for audit or access=
 control (but doesn't have to be). Which, I guess, is to say that your =
worries were indeed a design goal of the document. That may not alleviate t=
hose worries but hopefully does provide some insight into the reasoning behind the current composite token approach. =




On Thu, Feb 23, 2017 a=
t 7:46 AM, Jan Brennenstuhl <jan.brennenstuhl@zalando.de>=
 wrote:
=
Hey everyone,

Let me shortly introduce myself - My name is Jan, I do IAM at Zaland=
o SE.

I am writing, because I like to =
get a better understanding of the reasoning behind a fundamental conceptual=
 decision that was made in the oauth-token-exchange draft.

=

The draft describes one possible design of a composite=
 token: an 'act' claim in a representee token, meaning that a regul=
ar principal token gives the information about a possible delegate/ agent a=
 piggyback. 

In my eyes, this is not q=
uite intuitive nor the most secure solution as:

  • the current approach cloaks the true nature of the=
 delegation as the actual actor is not represented by/ in the primary token=
,
  • the current approach would be entirely transparent for old/ legacy sy=
stems which do not know about a possible act claim. Those applications, wou=
ld support delegation simply because they do not know any better. For them,=
 the intended delegation would look like a true impersonation.
    =


As delegation usually is a highly securi=
ty sensitive thing to do, I personally would prefer the probably more secur=
e approach of defining a primary agent token with a nested representee toke=
n/ information. This would lead to systems not just silently supporting del=
egation (without knowing about it). They would need to explicitly support t=
he spec if they want to support delegation.

My questions now are:
  • a=
m I missing something here,
  • do you share my worries, 
    • =

  • what are the =
actual reasons for the current composite token design?

    • Would be great if you could provide some backgro=
und info on why you chose to follow the current approach.

    <=
span style=3D"font-variant-ligatures:normal;font-variant-numeric:normal;fon=
t-variant-alternates:normal;font-variant-east-asian:normal;vertical-align:b=
aseline;white-space:pre-wrap">Thanks, Jan

_________________=
______________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





--94eb2c19a52cc573fa05499ea533--


From nobody Tue Feb 28 16:24:09 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB931293E9 for ; Tue, 28 Feb 2017 16:24:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=teamtelstra.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrYds8d8vZ9s for ; Tue, 28 Feb 2017 16:24:02 -0800 (PST)
Received: from ipxdno.tcif.telstra.com.au (ipxdno.tcif.telstra.com.au [203.35.82.212]) (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 407A312941D for ; Tue, 28 Feb 2017 16:23:59 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.35,222,1483966800"; d="scan'208,217";a="1642391"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipodni.tcif.telstra.com.au with ESMTP; 01 Mar 2017 11:23:56 +1100
X-IronPort-AV: E=McAfee;i="5800,7501,8453"; a="295547123"
Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcani.tcif.telstra.com.au with ESMTP; 01 Mar 2017 11:23:56 +1100
Received: from wsapp5863.srv.dir.telstra.com (10.75.131.32) by wsmsg3702.srv.dir.telstra.com (172.49.40.170) with Microsoft SMTP Server (TLS) id 8.3.485.1; Wed, 1 Mar 2017 11:23:56 +1100
Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5863.srv.dir.telstra.com (10.75.131.32) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 1 Mar 2017 11:23:55 +1100
Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.101.126) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Wed, 1 Mar 2017 11:23:55 +1100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WDi/RiEe+95NeaGDGCPcyRk5fDdbWIVTNihN+eN6lfY=; b=e2n9RQTAlnlmD8yCg20h6WhSy612Wf300ACCAhDPZLnWqzz+ArMJQYCUunawN5g5thc5sEisC5lTaY7vJkJ603PzH86srxsRXeVuXSVpExjIS9TwOIAGqaAQJ4e/KbU08uISaxeoe2rY3EdsU1UsPnQqEpEpbqFzQx9lg5w0+10=
Received: from SYXPR01MB1615.ausprd01.prod.outlook.com (10.175.209.15) by SYXPR01MB1615.ausprd01.prod.outlook.com (10.175.209.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Wed, 1 Mar 2017 00:23:51 +0000
Received: from SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) by SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) with mapi id 15.01.0933.020; Wed, 1 Mar 2017 00:23:51 +0000
From: "Manger, James" 
To: "oauth@ietf.org" , William Denniss ,  "mbj@microsoft.com" , "ve7jtb@ve7jtb.com" , "Hannes.Tschofenig@gmx.net" 
Thread-Topic: draft-ietf-oauth-device-flow: url with code
Thread-Index: AdKRRh/IkJeVOoDTRW+gjblgguPT/QA23hYg
Date: Wed, 1 Mar 2017 00:23:51 +0000
Message-ID: 
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; 
x-originating-ip: [203.35.9.18]
x-ms-office365-filtering-correlation-id: 27780d37-910b-4278-7437-08d460393cdb
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SYXPR01MB1615;
x-microsoft-exchange-diagnostics: 1; SYXPR01MB1615; 7:h1+JogIuOvRmQYzlisfZmsRy8dOBPqyyxzEGjyidOG1LjVAfrq/aV4fXjcBxA4ZP6uuPvVr9I3FXDy0WQJlaIlHA64ospftTUg0/0QLdB3URG5j8bMkjJpz9uSQHDvYBVsGgr9qLDa67eOfVKNMLRAd5HEFSeH0OP2GS9VVKzPk3H9fTj2dalQXLgS48WVAZ8uMvAqhUexukvZMrfFvczk9a/3UtZeML8dw+2Ad0tdVSYKjVnkFm8js53VHdPlTrGOO5bukFYOlW9FlBPFwvqlJdTmzvspqjMR17Ug3BzQrYmoGNvsAYYGPjJ3/ZbLRdSNaNfzfoczjtt9wQTn3wQQ==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:SYXPR01MB1615; BCL:0; PCL:0; RULEID:; SRVR:SYXPR01MB1615; 
x-forefront-prvs: 0233768B38
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(377454003)(189002)(199003)(24454002)(86362001)(2201001)(2421001)(5660300001)(1511001)(92566002)(53546006)(7696004)(53936002)(38730400002)(42882006)(101416001)(229853002)(54356999)(2900100001)(6436002)(7736002)(66066001)(50986999)(606005)(77096006)(74316002)(33656002)(6506006)(25786008)(7906003)(106356001)(55016002)(105586002)(230783001)(6306002)(9686003)(54896002)(97736004)(236005)(99286003)(8666007)(189998001)(3280700002)(2473003)(122556002)(8676002)(2561002)(2906002)(68736007)(3660700001)(790700001)(81156014)(81166006)(8936002)(102836003)(6116002)(3846002)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:SYXPR01MB1615; H:SYXPR01MB1615.ausprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:0; LANG:en; 
received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_SYXPR01MB16152987001DF96C3660FD6DE5290SYXPR01MB1615ausp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 00:23:51.5093 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1615
X-OriginatorOrg: team.telstra.com
Archived-At: 
Subject: [OAUTH-WG] FW: draft-ietf-oauth-device-flow: url with code
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Mar 2017 00:24:06 -0000

--_000_SYXPR01MB16152987001DF96C3660FD6DE5290SYXPR01MB1615ausp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UmVzZW5kaW5nOyBub3Qgc3VyZSB0aGF0IE9BdXRoIGVtYWlsIGxpc3QgaXMgd29ya2luZyBhdCB0
aGUgbW9tZW50Lg0KDQpGcm9tOiBNYW5nZXIsIEphbWVzDQpTZW50OiBUdWVzZGF5LCAyOCBGZWJy
dWFyeSAyMDE3IDk6NTMgQU0NClRvOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogZHJhZnQtaWV0
Zi1vYXV0aC1kZXZpY2UtZmxvdzogdXJsIHdpdGggY29kZQ0KDQpIb3cgYWJvdXQgY29tYmluaW5n
IHRoZSB2ZXJpZmljYXRpb25fdXJpIGFuZCB1c2VyX2NvZGU/DQoNClRoZSBEZXZpY2UgRmxvdyBw
cm92aWRlcyBhIHZlcmlmaWNhdGlvbl91cmkgYW5kIHVzZXJfY29kZSwgYm90aCBvZiB3aGljaCBo
YXZlIHRvIGJlIGNvcGllZCB0byBhIHdlYiBicm93c2VyIG9uLCBzYXksIGEgbW9iaWxlIHBob25l
LiBUaGUgbWFpbiBtb2RlbCBpbiB0aGlzIGRyYWZ0IGlzIHRoYXQgdGhlIHVzZXIgY29waWVzIHRo
ZSB1cmksIHRoZW4gdGhlIHJlc3VsdGluZyB3ZWIgcGFnZSBwcm9tcHRzIGZvciB0aGUgY29kZS4g
VGhlIGRyYWZ0IGFsc28gbWVudGlvbnMgb3RoZXIgcG9zc2liaWxpdGllcyBzdWNoIGFzIEJsdWV0
b290aCB0byBkbyB0aGUg4oCcY29weWluZ+KAnS4gVHJhbnNtaXR0aW5nIGEgVVJJIHZpYSBCbHVl
dG9vdGgsIG9yIE5GQywgb3IgUVIgY29kZSwgaXMgcXVpdGUgY29tbW9uLiBJbiBzdWNoIGNhc2Vz
IGl0IHdvdWxkIGJlIG5pY2VyIHRvIHRyYW5zbWl0IHRoZSB1c2VyX2NvZGUgYXMgcGFydCBvZiB0
aGUgVVJJLg0KDQpQZXJoYXBzIGJvdGggbW9kZXMgY291bGQgYmUgc3VwcG9ydGVkIGJ5IHNheWlu
ZyB0aGUgdXNlcl9jb2RlIGNhbiBiZSBpbmNsdWRlZCBhcyBhIHF1ZXJ5IHBhcmFtZXRlciBvbiB0
aGUgdmVyaWZpY2F0aW9uX3VyaSB3aGVuIGl0IGlzIG1vcmUgY29udmVuaWVudCBmb3IgYSBkZXZp
Y2UgdG8gdHJhbnNtaXQgYSBzaW5nbGUgVVJJLiBBdXRob3JpemF0aW9uIFNlcnZlcnMgTVVTVCBh
Y2NlcHQgdGhpcy4gVGhlIGNob2ljZSBpcyB0byB1c2UgdXNlcl9jb2RlIGFzIHRoZSBjb21wbGV0
ZSBxdWVyeSBzdHJpbmcgKGVnIGh0dHBzOi8vZXhhbXBsZS5jb20vZGV2aWNlP3dkamItbWpodCkg
b3Igc3BlY2lmeSBhIOKAnGNvZGXigJ0gcGFyYW1ldGVyIG5hbWUgKGVnIGh0dHBzOi8vZXhhbXBs
ZS5jb20vZGV2aWNlP2NvZGU9d2RqYi1tamh0KS4NCg0KDQpSZWNvbW1lbmRpbmcgY2FzZS1pbnNl
bnNpdGl2ZSBwdW5jdHVhdGlvbi1pZ25vcmluZyBhbHBoYWJldGljIGNvZGVzIGlzIGdvb2QsIGJ1
dCBob3cgZG9lcyBhIHVzZXIga25vdyB0aGlzIGlzIHRoZSBjYXNlIGZvciBhIHBhcnRpY3VsYXIg
Y29kZT8gUGVyaGFwcyB0aGUgYWR2aWNlIG5lZWRzIHRvIGJlIHRvIHVzZSBhIOKAnGZhbmN54oCd
IGlucHV0IGZpZWxkIHdpdGggamF2YXNjcmlwdCB0byBjb252ZXJ0IHRvIHVwcGVyY2FzZSBhcyB0
aGUgdXNlciB0eXBlcyBhbmQgaGFuZGxlIHB1bmN0dWF0aW9uPw0KDQoNClvCpzYuMV0gVGhlIGV4
YW1wbGUgdXNlciBjb2RlIOKAnFdESkItTUpIVOKAnSBkb2VzbuKAmXQgaGF2ZSDigJwyNF44IGJp
dHMgb2YgZW50cm9weeKAnSwgYnV0IOKAnGxvZzIoMjQgXiA4KSA9IDM2LjcgYml0cyBvZiBlbnRy
b3B54oCdLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0KT24gTW9uLCBGZWIgMjcsIDIwMTcgYXQg
OTo0NiBBTSwgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRz
QGlldGYub3JnPj4gd3JvdGU6DQogICAgICAgIFRpdGxlICAgICAgICAgICA6IE9BdXRoIDIuMCBE
ZXZpY2UgRmxvdyBmb3IgQnJvd3Nlcmxlc3MgYW5kIElucHV0IENvbnN0cmFpbmVkIERldmljZXMN
CiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxvdy0w
NC50eHQNCg0KQWJzdHJhY3Q6DQogICBUaGlzIE9BdXRoIDIuMCBhdXRob3JpemF0aW9uIGZsb3cg
Zm9yIGJyb3dzZXJsZXNzIGFuZCBpbnB1dA0KICAgY29uc3RyYWluZWQgZGV2aWNlcywgb2Z0ZW4g
cmVmZXJyZWQgdG8gYXMgdGhlIGRldmljZSBmbG93LCBlbmFibGVzDQogICBPQXV0aCBjbGllbnRz
IHRvIHJlcXVlc3QgdXNlciBhdXRob3JpemF0aW9uIGZyb20gZGV2aWNlcyB0aGF0IGhhdmUgYW4N
CiAgIEludGVybmV0IGNvbm5lY3Rpb24sIGJ1dCBkb24ndCBoYXZlIGFuIGVhc3kgaW5wdXQgbWV0
aG9kIChzdWNoIGFzIGENCiAgIHNtYXJ0IFRWLCBtZWRpYSBjb25zb2xlLCBwaWN0dXJlIGZyYW1l
LCBvciBwcmludGVyKSwgb3IgbGFjayBhDQogICBzdWl0YWJsZSBicm93c2VyIGZvciBhIG1vcmUg
dHJhZGl0aW9uYWwgT0F1dGggZmxvdy4gIFRoaXMNCiAgIGF1dGhvcml6YXRpb24gZmxvdyBpbnN0
cnVjdHMgdGhlIHVzZXIgdG8gcGVyZm9ybSB0aGUgYXV0aG9yaXphdGlvbg0KICAgcmVxdWVzdCBv
biBhIHNlY29uZGFyeSBkZXZpY2UsIHN1Y2ggYXMgYSBzbWFydHBob25lLiAgVGhlcmUgaXMgbm8N
CiAgIHJlcXVpcmVtZW50IGZvciBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhlIGNvbnN0cmFpbmVk
IGRldmljZSBhbmQgdGhlDQogICB1c2VyJ3Mgc2Vjb25kYXJ5IGRldmljZS4NCg0KaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtZGV2aWNlLWZsb3ctMDQNCg0K

--_000_SYXPR01MB16152987001DF96C3660FD6DE5290SYXPR01MB1615ausp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y
OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt
Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k
b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3
OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg
Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs
YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8
L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF
Ti1BVSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv
bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlc2VuZGluZzsgbm90IHN1cmUgdGhhdCBPQXV0
aCBlbWFpbCBsaXN0IGlzIHdvcmtpbmcgYXQgdGhlIG1vbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt
c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx
LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n
PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj4gTWFuZ2VyLCBKYW1lcw0KPGJyPg0KPGI+U2VudDo8L2I+IFR1
ZXNkYXksIDI4IEZlYnJ1YXJ5IDIwMTcgOTo1MyBBTTxicj4NCjxiPlRvOjwvYj4gb2F1dGhAaWV0
Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gZHJhZnQtaWV0Zi1vYXV0aC1kZXZpY2UtZmxvdzog
dXJsIHdpdGggY29kZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO
LVVTIj5Ib3cgYWJvdXQgY29tYmluaW5nIHRoZSB2ZXJpZmljYXRpb25fdXJpIGFuZCB1c2VyX2Nv
ZGU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgRGV2aWNlIEZs
b3cgcHJvdmlkZXMgYSB2ZXJpZmljYXRpb25fdXJpIGFuZCB1c2VyX2NvZGUsIGJvdGggb2Ygd2hp
Y2ggaGF2ZSB0byBiZSBjb3BpZWQgdG8gYSB3ZWIgYnJvd3NlciBvbiwgc2F5LCBhIG1vYmlsZSBw
aG9uZS4NCiBUaGUgbWFpbiBtb2RlbCBpbiB0aGlzIGRyYWZ0IGlzIHRoYXQgdGhlIHVzZXIgY29w
aWVzIHRoZSB1cmksIHRoZW4gdGhlIHJlc3VsdGluZyB3ZWIgcGFnZSBwcm9tcHRzIGZvciB0aGUg
Y29kZS4gVGhlIGRyYWZ0IGFsc28gbWVudGlvbnMgb3RoZXIgcG9zc2liaWxpdGllcyBzdWNoIGFz
IEJsdWV0b290aCB0byBkbyB0aGUg4oCcY29weWluZ+KAnS4gVHJhbnNtaXR0aW5nIGEgVVJJIHZp
YSBCbHVldG9vdGgsIG9yIE5GQywgb3IgUVIgY29kZSwgaXMgcXVpdGUNCiBjb21tb24uIEluIHN1
Y2ggY2FzZXMgaXQgd291bGQgYmUgbmljZXIgdG8gdHJhbnNtaXQgdGhlIHVzZXJfY29kZSBhcyBw
YXJ0IG9mIHRoZSBVUkkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Q
ZXJoYXBzIGJvdGggbW9kZXMgY291bGQgYmUgc3VwcG9ydGVkIGJ5IHNheWluZyB0aGUgdXNlcl9j
b2RlIGNhbiBiZSBpbmNsdWRlZCBhcyBhIHF1ZXJ5IHBhcmFtZXRlciBvbiB0aGUgdmVyaWZpY2F0
aW9uX3VyaSB3aGVuIGl0DQogaXMgbW9yZSBjb252ZW5pZW50IGZvciBhIGRldmljZSB0byB0cmFu
c21pdCBhIHNpbmdsZSBVUkkuIEF1dGhvcml6YXRpb24gU2VydmVycyBNVVNUIGFjY2VwdCB0aGlz
LiBUaGUgY2hvaWNlIGlzIHRvIHVzZSB1c2VyX2NvZGUgYXMgdGhlIGNvbXBsZXRlIHF1ZXJ5IHN0
cmluZyAoZWcNCjxhIGhyZWY9Imh0dHBzOi8vZXhhbXBsZS5jb20vZGV2aWNlP3dkamItbWpodCI+
aHR0cHM6Ly9leGFtcGxlLmNvbS9kZXZpY2U/d2RqYi1tamh0PC9hPikgb3Igc3BlY2lmeSBhIOKA
nGNvZGXigJ0gcGFyYW1ldGVyIG5hbWUgKGVnDQo8YSBocmVmPSJodHRwczovL2V4YW1wbGUuY29t
L2RldmljZT9jb2RlPXdkamItbWpodCI+aHR0cHM6Ly9leGFtcGxlLmNvbS9kZXZpY2U/Y29kZT13
ZGpiLW1qaHQ8L2E+KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWNvbW1l
bmRpbmcgY2FzZS1pbnNlbnNpdGl2ZSBwdW5jdHVhdGlvbi1pZ25vcmluZyBhbHBoYWJldGljIGNv
ZGVzIGlzIGdvb2QsIGJ1dCBob3cgZG9lcyBhIHVzZXIga25vdyB0aGlzIGlzIHRoZSBjYXNlIGZv
ciBhIHBhcnRpY3VsYXINCiBjb2RlPyBQZXJoYXBzIHRoZSBhZHZpY2UgbmVlZHMgdG8gYmUgdG8g
dXNlIGEg4oCcZmFuY3nigJ0gaW5wdXQgZmllbGQgd2l0aCBqYXZhc2NyaXB0IHRvIGNvbnZlcnQg
dG8gdXBwZXJjYXNlIGFzIHRoZSB1c2VyIHR5cGVzIGFuZCBoYW5kbGUgcHVuY3R1YXRpb24/PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+W8KnNi4xXSBUaGUgZXhhbXBsZSB1c2Vy
IGNvZGUg4oCcV0RKQi1NSkhU4oCdIGRvZXNu4oCZdCBoYXZlIOKAnDI0XjggYml0cyBvZiBlbnRy
b3B54oCdLCBidXQg4oCcbG9nMigyNCBeIDgpID0gMzYuNyBiaXRzIG9mIGVudHJvcHnigJ0uPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tLTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBGZWIgMjcsIDIw
MTcgYXQgOTo0NiBBTSwgJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90
ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu
LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu
MHB0Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogT0F1dGggMi4wIERldmljZSBGbG93IGZvciBCcm93c2Vy
bGVzcyBhbmQgSW5wdXQgQ29uc3RyYWluZWQgRGV2aWNlczxicj4NCiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWll
dGYtb2F1dGgtZGV2aWNlLWZsb3ctMDQudHh0PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5i
c3A7ICZuYnNwO1RoaXMgT0F1dGggMi4wIGF1dGhvcml6YXRpb24gZmxvdyBmb3IgYnJvd3Nlcmxl
c3MgYW5kIGlucHV0PGJyPg0KJm5ic3A7ICZuYnNwO2NvbnN0cmFpbmVkIGRldmljZXMsIG9mdGVu
IHJlZmVycmVkIHRvIGFzIHRoZSBkZXZpY2UgZmxvdywgZW5hYmxlczxicj4NCiZuYnNwOyAmbmJz
cDtPQXV0aCBjbGllbnRzIHRvIHJlcXVlc3QgdXNlciBhdXRob3JpemF0aW9uIGZyb20gZGV2aWNl
cyB0aGF0IGhhdmUgYW48YnI+DQombmJzcDsgJm5ic3A7SW50ZXJuZXQgY29ubmVjdGlvbiwgYnV0
IGRvbid0IGhhdmUgYW4gZWFzeSBpbnB1dCBtZXRob2QgKHN1Y2ggYXMgYTxicj4NCiZuYnNwOyAm
bmJzcDtzbWFydCBUViwgbWVkaWEgY29uc29sZSwgcGljdHVyZSBmcmFtZSwgb3IgcHJpbnRlciks
IG9yIGxhY2sgYTxicj4NCiZuYnNwOyAmbmJzcDtzdWl0YWJsZSBicm93c2VyIGZvciBhIG1vcmUg
dHJhZGl0aW9uYWwgT0F1dGggZmxvdy4mbmJzcDsgVGhpczxicj4NCiZuYnNwOyAmbmJzcDthdXRo
b3JpemF0aW9uIGZsb3cgaW5zdHJ1Y3RzIHRoZSB1c2VyIHRvIHBlcmZvcm0gdGhlIGF1dGhvcml6
YXRpb248YnI+DQombmJzcDsgJm5ic3A7cmVxdWVzdCBvbiBhIHNlY29uZGFyeSBkZXZpY2UsIHN1
Y2ggYXMgYSBzbWFydHBob25lLiZuYnNwOyBUaGVyZSBpcyBubzxicj4NCiZuYnNwOyAmbmJzcDty
ZXF1aXJlbWVudCBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHRoZSBjb25zdHJhaW5lZCBkZXZp
Y2UgYW5kIHRoZTxicj4NCiZuYnNwOyAmbmJzcDt1c2VyJ3Mgc2Vjb25kYXJ5IGRldmljZS48YnI+
DQo8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v
YXV0aC1kZXZpY2UtZmxvdy0wNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRldmljZS1mbG93LTA0PC9hPjxvOnA+PC9vOnA+PC9w
Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_SYXPR01MB16152987001DF96C3660FD6DE5290SYXPR01MB1615ausp_--


From nobody Tue Feb 28 16:40:16 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80DE1297A7 for ; Tue, 28 Feb 2017 16:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGftkpVkL9i3 for ; Tue, 28 Feb 2017 16:40:12 -0800 (PST)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 3486F1293EB for ; Tue, 28 Feb 2017 16:40:12 -0800 (PST)
Received: by mail-qk0-x234.google.com with SMTP id n186so45031834qkb.3 for ; Tue, 28 Feb 2017 16:40:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SC9FWkjsTqufscfWbi4iNX21ZF38Y6VVSVm48Ep75FM=; b=X3JMk6eZpv7IKTLtzgwmRqUipPtc2hvEclASFFdaVhGG6RY6Bxkp9xnYVh6jMJOWUz yRYaREBS/jqEr9glPE9XB/xiH9ImPf2TB1+fQV6mVrRn3S8eD+JNnzwBVzig3cb9A+Lj 1itJCZrkBj+7RQ+KnqoJPSiI9EausvkRypmx5pO7fSiRL2JONGOuKNTrUrSXSz1JkLni r+0aBz2XwxmAEwOVTcbKffdMkH42WRwb8V5LipJDqv7XD2T5opn5ia3Ah8luoCLSNFcg gFnZuqBTshNuTKQptHoZOKl2B6BlXYWJMY9xeJUkalBWPQoDoohCL89HwF+DGpD02aEd z6qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SC9FWkjsTqufscfWbi4iNX21ZF38Y6VVSVm48Ep75FM=; b=LuQ7nf5JwT6LOqHNHNJvARCEm/1ITRWlWTgyIlh575XvXqAoVYa8HBb9C2W9TQ+J6u 9n60+U0EERH4vbJ5D0aC9q7SviW8cTouufzYKA1r9uisQ0GjmEHXHHwBijpMvb3jXRu9 Er5dTfg74tnYVPGvLjs8BCuI6ifBrtDHy6o9n3IFnA0oWEa0+3Tyv7tlSOBQa+L1DMla IgLMpDLRVXIdI4p0yHmkL7zbKOhuxLYEvZljaab2mltcbV2vIDDXx23ya7aQduUIStTb +cr4h62am3zWdzfXUURyJVwka9pxbnhf0ZEgompJ58Mzz1v9AXE9nnCY2vbsjNqc7pGr G7YA==
X-Gm-Message-State: AMke39mhDz/rxHBBIR3ops4fftQ29WGvnjESQT2p7GLLVZ2oCwFemotTlPO4yJxtElVikFQN+t/EYAPzGHVJJ2YZ
X-Received: by 10.237.62.9 with SMTP id l9mr6866150qtf.198.1488328810996; Tue, 28 Feb 2017 16:40:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.36.203 with HTTP; Tue, 28 Feb 2017 16:39:50 -0800 (PST)
In-Reply-To: 
References: 
From: William Denniss 
Date: Tue, 28 Feb 2017 16:39:50 -0800
Message-ID: 
To: "Manger, James" 
Content-Type: multipart/alternative; boundary=001a1140868a1713190549a08e77
Archived-At: 
Cc: "mbj@microsoft.com" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] FW: draft-ietf-oauth-device-flow: url with code
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Mar 2017 00:40:15 -0000

--001a1140868a1713190549a08e77
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for your review James!

On Tue, Feb 28, 2017 at 4:23 PM, Manger, James <
James.H.Manger@team.telstra.com> wrote:

> Resending; not sure that OAuth email list is working at the moment.
>
>
>
> *From:* Manger, James
> *Sent:* Tuesday, 28 February 2017 9:53 AM
> *To:* oauth@ietf.org
> *Subject:* draft-ietf-oauth-device-flow: url with code
>
>
>
> How about combining the verification_uri and user_code?
>
>
>
> The Device Flow provides a verification_uri and user_code, both of which
> have to be copied to a web browser on, say, a mobile phone. The main mode=
l
> in this draft is that the user copies the uri, then the resulting web pag=
e
> prompts for the code.
>

Correct. And note that there is a high probability that the user will make
errors, one reason why it's better for them to get the URI input first
(which may get browser auto-complete), before asking for the code.


> The draft also mentions other possibilities such as Bluetooth to do the
> =E2=80=9Ccopying=E2=80=9D. Transmitting a URI via Bluetooth, or NFC, or Q=
R code, is quite
> common. In such cases it would be nicer to transmit the user_code as part
> of the URI.
>

I don't really see the benefit.

If you're doing some kind of out-of-band transmission (which is mentioned
as out of scope of the spec) there's no reason you can't simply transmit
both pieces of information.  We've done that before, and this is what we
do.  Having the data separate did not really alter the implementation of
this, and combining it wouldn't measurably make it simpler (but it would
make the spec more complex).

Also if the AS really wanted to, there's nothing to stop it including
whatever parameters it wanted in the verification URI today (which could
include the user code).

So I'd prefer to keep 1 protocol, designed for the browser model (which is
the only thing in-scope in the spec), that can potentially work with a wide
range of cases.


> Perhaps both modes could be supported by saying the user_code can be
> included as a query parameter on the verification_uri when it is more
> convenient for a device to transmit a single URI. Authorization Servers
> MUST accept this. The choice is to use user_code as the complete query
> string (eg https://example.com/device?wdjb-mjht) or specify a =E2=80=9Cco=
de=E2=80=9D
> parameter name (eg https://example.com/device?code=3Dwdjb-mjht).
>

-1. I know for sure Google's AS will not comply with that MUST. As it is
there are some phishing concerns around this flow (documented in the spec),
and this change unfortunately makes the matter worse by allowing for
single-click phishing.

For example, we use the text today: "Enter the code displayed on your
device". And we display a picture picture of the device to help guide the
user as to the expected usage of this flow (this by itself isn't everything
=E2=80=93 but they are important hints).


> Recommending case-insensitive punctuation-ignoring alphabetic codes is
> good, but how does a user know this is the case for a particular code?
> Perhaps the advice needs to be to use a =E2=80=9Cfancy=E2=80=9D input fie=
ld with javascript
> to convert to uppercase as the user types and handle punctuation?
>

I believe that's covered:

   The server should ignore any characters like punctuation that are not
   in the user-code character set.  Provided that the character set
   doesn't include characters of different case, the comparison should
   be case insensitive.



>
>
>
>
> [=C2=A76.1] The example user code =E2=80=9CWDJB-MJHT=E2=80=9D doesn=E2=80=
=99t have =E2=80=9C24^8 bits of
> entropy=E2=80=9D, but =E2=80=9Clog2(24 ^ 8) =3D 36.7 bits of entropy=E2=
=80=9D.
>

Good point.

Best,
William


>
> --
>
> James Manger
>
>
>
>
>
> On Mon, Feb 27, 2017 at 9:46 AM,  wrote:
>
>         Title           : OAuth 2.0 Device Flow for Browserless and Input
> Constrained Devices
>         Filename        : draft-ietf-oauth-device-flow-04.txt
>
> Abstract:
>    This OAuth 2.0 authorization flow for browserless and input
>    constrained devices, often referred to as the device flow, enables
>    OAuth clients to request user authorization from devices that have an
>    Internet connection, but don't have an easy input method (such as a
>    smart TV, media console, picture frame, or printer), or lack a
>    suitable browser for a more traditional OAuth flow.  This
>    authorization flow instructs the user to perform the authorization
>    request on a secondary device, such as a smartphone.  There is no
>    requirement for communication between the constrained device and the
>    user's secondary device.
>
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04
>
>
>

--001a1140868a1713190549a08e77
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks for your review James!

On Tue, Feb 28, 2017 at 4:23 PM, Manger, J=
ames <James.H.Manger@team.telstra.com> wrote:<=
br>











Resending; not sure that OAuth email list is=
 working at the moment.


=C2=A0






From: Manger, James


Sent: Tuesday, 28 February 2017 9:53 AM

To: oauth@ietf.o=
rg

Subject: draft-ietf-oauth-device-flow: url with code






=C2=A0


How about combining the verification_uri and=
 user_code?


=C2=A0


The Device Flow provides a verification_uri =
and user_code, both of which have to be copied to a web browser on, say, a =
mobile phone.
 The main model in this draft is that the user copies the uri, then the res=
ulting web page prompts for the code. 
<=
div>
Correct. And note that there is a high probability that =
the user will make errors, one reason why it's better for them to get t=
he URI input first (which may get browser auto-complete), before asking for=
 the code.
=C2=A0
The draft also mentions other possib=
ilities such as Bluetooth to do the =E2=80=9Ccopying=E2=80=9D. Transmitting=
 a URI via Bluetooth, or NFC, or QR code, is quite
 common. In such cases it would be nicer to transmit the user_code as part =
of the URI.

I don=
9;t really see the benefit.

If you're doing so=
me kind of out-of-band transmission (which is mentioned as out of scope of =
the spec) there's no reason you can't simply transmit both pieces o=
f information.=C2=A0 We've done that before, and this is what we do.=C2=
=A0 Having the data separate did not really alter the implementation of thi=
s, and combining it wouldn't measurably make it simpler (but it would m=
ake the spec more complex).

Also if the AS really =
wanted to, there's nothing to stop it including whatever parameters it =
wanted in the verification URI today (which could include the user code).

So I'd prefer to keep 1 protocol, designed for =
the browser model (which is the only thing in-scope in the spec), that can =
potentially work with a wide range of cases.
=C2=A0


Perhaps both modes could be supported by say=
ing the user_code can be included as a query parameter on the verification_=
uri when it
 is more convenient for a device to transmit a single URI. Authorization Se=
rvers MUST accept this. The choice is to use user_code as the complete quer=
y string (eg
https://=
example.com/device?wdjb-mjht) or specify a =E2=80=9Ccode=E2=80=9D =
parameter name (eg
h=
ttps://example.com/device?code=3Dwdjb-mjht).

-1. I know for sure Google's AS will =
not comply with that MUST. As it is there are some phishing concerns around=
 this flow (documented in the spec), and this change unfortunately makes th=
e matter worse by allowing for single-click phishing.

<=
div>For example, we use the text today: "Enter the code displayed on y=
our device". And we display a picture picture of the device to help gu=
ide the user as to the expected usage of this flow (this by itself isn'=
t everything =E2=80=93 but they are important hints).
=C2=
=A0


Recommending case-insensitive punctuation-ig=
noring alphabetic codes is good, but how does a user know this is the case =
for a particular
 code? Perhaps the advice needs to be to use a =E2=80=9Cfancy=E2=80=9D inpu=
t field with javascript to convert to uppercase as the user types and handl=
e punctuation?

I bel=
ieve that's covered:

   The server should ignore any characters like punctuation that a=
re not
   in the user-code character set.  Provided that the character set
   doesn't include characters of different case, the comparison should
   be case insensitive.
=C2=A0


=C2=A0


=C2=A0


[=C2=A76.1] The example user code =E2=80=9CW=
DJB-MJHT=E2=80=9D doesn=E2=80=99t have =E2=80=9C24^8 bits of entropy=E2=80=
=9D, but =E2=80=9Clog2(24 ^ 8) =3D 36.7 bits of entropy=E2=80=9D.

Good point.
=C2=A0<=
/div>
Best,
William

<=
/span>


=C2=A0


--


James Manger


=C2=A0








=C2=A0




On Mon, Feb 27, 2017 at 9:46 AM, <internet-drafts@ietf.org=
> wrote:




=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: OAuth 2.0 Device Flo=
w for Browserless and Input Constrained Devices

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-device-flow-04.txt



Abstract:

=C2=A0 =C2=A0This OAuth 2.0 authorization flow for browserless and input
=C2=A0 =C2=A0constrained devices, often referred to as the device flow, ena=
bles

=C2=A0 =C2=A0OAuth clients to request user authorization from devices that =
have an

=C2=A0 =C2=A0Internet connection, but don't have an easy input method (=
such as a

=C2=A0 =C2=A0smart TV, media console, picture frame, or printer), or lack a=


=C2=A0 =C2=A0suitable browser for a more traditional OAuth flow.=C2=A0 This=


=C2=A0 =C2=A0authorization flow instructs the user to perform the authoriza=
tion

=C2=A0 =C2=A0request on a secondary device, such as a smartphone.=C2=A0 The=
re is no

=C2=A0 =C2=A0requirement for communication between the constrained device a=
nd the

=C2=A0 =C2=A0user's secondary device.



https://tools.ietf.org/html/draft-ietf-oauth-device-flo=
w-04






=C2=A0
















--001a1140868a1713190549a08e77--


From nobody Tue Feb 28 18:07:08 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4969129469 for ; Tue, 28 Feb 2017 18:07:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=teamtelstra.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ej8ODdO1PMTK for ; Tue, 28 Feb 2017 18:07:04 -0800 (PST)
Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) (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 103E5126DFB for ; Tue, 28 Feb 2017 18:07:03 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.35,222,1483966800"; d="scan'208";a="26282768"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 01 Mar 2017 13:07:01 +1100
X-IronPort-AV: E=McAfee;i="5800,7501,8453"; a="312440296"
Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbni.tcif.telstra.com.au with ESMTP; 01 Mar 2017 13:07:00 +1100
Received: from wsapp5871.srv.dir.telstra.com (10.75.139.13) by wsmsg3757.srv.dir.telstra.com (172.49.40.85) with Microsoft SMTP Server (TLS) id 8.3.485.1; Wed, 1 Mar 2017 13:07:01 +1100
Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5871.srv.dir.telstra.com (10.75.139.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 1 Mar 2017 13:06:59 +1100
Received: from AUS01-ME1-obe.outbound.protection.outlook.com (10.172.101.126) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Wed, 1 Mar 2017 13:06:59 +1100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aEUCc97t5bRG3Tl0VqvofTR4QZ7BYZOUYQEAt0aEQKw=; b=IuuHdBLkzO/h98VGGphjflIr48VtCPZs4DFN8nS/m85IBQL2p8Y6l3FBPzKw2jq8VJna8bSKdLEqIkzxMbq1stvfx2h3z0eDu4aMXJCNDtiIZEeqBHZaOnpomr1HmXSKomM2NVZ5ZpSPovcjCENvMNuIW1qSjl+RyqNa5CsgMfQ=
Received: from SYXPR01MB1615.ausprd01.prod.outlook.com (10.175.209.15) by SYXPR01MB1616.ausprd01.prod.outlook.com (10.175.209.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Wed, 1 Mar 2017 02:06:58 +0000
Received: from SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) by SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) with mapi id 15.01.0933.020; Wed, 1 Mar 2017 02:06:58 +0000
From: "Manger, James" 
To: William Denniss 
Thread-Topic: FW: draft-ietf-oauth-device-flow: url with code
Thread-Index: AdKRRh/IkJeVOoDTRW+gjblgguPT/QA23hYgAACvXwAAACL3EA==
Date: Wed, 1 Mar 2017 02:06:58 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com; 
x-originating-ip: [203.35.9.18]
x-ms-office365-filtering-correlation-id: db13b22c-f483-4e4d-d2b7-08d46047a4ad
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SYXPR01MB1616;
x-microsoft-exchange-diagnostics: 1; SYXPR01MB1616; 7:8mqmqIyit7tY5zmH1QudT4WMy/ScTlxubhZIoAAzS0EYeIxKFijJRL6JV6gmZxMX3cy/qMe6bmdGlYaSAa8FmsUHePH0cqVn5xlWZhuIGo/4UinQ7gbbYWoQqyQJCl+WNjb/K0EBcHpCNfaGgKVHzX6RbtXgz0i8ywJm8VxTZuCQ6HhcYqHaqF7h+v2VDk9qTi6w3hOwOxnZLGS4vI0fknEUFonYuGA93RFFIDT3PNEyiovQWDYBONgUtksyfMiUaMCKBJei4hFVdVoG6L461H/x+Ss/2F5QFo2/iI+8SRUSWC9h3Bdd3RTrgw2bg732vMk/sbiLZmO4Kx2JLuz/fw==
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123560025)(20161123564025)(6072148)(6042181); SRVR:SYXPR01MB1616; BCL:0; PCL:0; RULEID:; SRVR:SYXPR01MB1616; 
x-forefront-prvs: 0233768B38
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(86362001)(25786008)(229853002)(2906002)(97736004)(7736002)(8936002)(101416001)(33656002)(3280700002)(6436002)(3660700001)(77096006)(6506006)(102836003)(6116002)(230783001)(81166006)(4326008)(81156014)(3846002)(5660300001)(92566002)(122556002)(68736007)(74316002)(8676002)(7696004)(53936002)(66066001)(42882006)(2950100002)(6916009)(105586002)(54356999)(99286003)(55016002)(189998001)(305945005)(6246003)(9686003)(6306002)(76176999)(50986999)(110136004)(38730400002)(106356001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SYXPR01MB1616; H:SYXPR01MB1615.ausprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:0; LANG:en; 
received-spf: None (protection.outlook.com: team.telstra.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 02:06:58.6788 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1616
X-OriginatorOrg: team.telstra.com
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] FW: draft-ietf-oauth-device-flow: url with code
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Mar 2017 02:07:07 -0000

Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWRldmljZS1m
bG93LTA0DQoNCj4+IFRyYW5zbWl0dGluZyBhIFVSSSB2aWEgQmx1ZXRvb3RoLCBvciBORkMsIG9y
IFFSIGNvZGUsIGlzIHF1aXRlIGNvbW1vbi4gSW4gc3VjaCBjYXNlcyBpdCB3b3VsZCBiZSBuaWNl
ciB0byB0cmFuc21pdCB0aGUgdXNlcl9jb2RlIGFzIHBhcnQgb2YgdGhlIFVSSS4NCg0KPiBJIGRv
bid0IHJlYWxseSBzZWUgdGhlIGJlbmVmaXQuDQoNCklmIHRoZSBkZXZpY2UgaXMgYWx3YXlzIHVz
ZWQgd2l0aCBhIHByZS1pbnN0YWxsZWQgY29tcGFuaW9uIG1vYmlsZSBhcHA6IG5vIGJlbmVmaXQu
DQpJZiB0aGUgZGV2aWNlIGhhcyBhbXBsZSBzY3JlZW4gc2l6ZSBmb3IgIlRvIHJlZ2lzdGVyLCB2
aXNpdCA8dXJpPiBhbmQgZW50ZXIgPGNvZGU+Ijogbm8gYmVuZWZpdC4NCklmIHRoZSBkZXZpY2Ug
Y2FuIHVzZSBORkMvQkxFL1FSLWNvZGUv4oCmIHRvIHRyYW5zbWl0IGEgVVJJOiBiZW5lZml0OyBj
YW4gZ2V0IHZlcmlmaWNhdGlvbl91cmkgYW5kIHVzZXJfY29kZSB0byBhIG1vYmlsZSBicm93c2Vy
IHdpdGhvdXQgYW55dGhpbmcgZWxzZSAob24gdGhlIGRldmljZSBvciBvbiB0aGUgbW9iaWxlKS4N
Cg0KU2NlbmFyaW86IGEgZGV2aWNlIHdpdGggbm8gc2NyZWVuLCBqdXN0IGEgZmV3IExFRHM7IHRo
ZSBpbnN0cnVjdGlvbnMgc2F5ICJ0byBhY3RpdmF0ZSwgdGFwIHRoZSBkZXZpY2Ugd2l0aCB5b3Vy
IG1vYmlsZSAoYWZ0ZXIgZW5hYmxpbmcgTkZDIG9yIGJsdWV0b290aCkiLg0KVXNlciB0YXBzIHdp
dGggbW9iaWxlOyBicm93c2VyIGxhdW5jaGVzOyBBUyBzaG93cyBwaWN0dXJlIG9mIGRldmljZSBh
bmQgYXNrcyB1c2VyIHRvIGNvbmZpcm0gTEVEcyBhcmUgZmxhc2hpbmcgcmVkL2dyZWVuL3JlZC9n
cmVlbuKApiAob24gZm9ybSB3aXRoIENTUkYtcHJvdGVjdGlvbik7IHVzZXIgY2xpY2sgWWVzOyBu
ZXh0IGRldmljZSBwb2xsaW5nIHRva2VuIHJlcXVlc3Qgc3VjY2VlZHMuDQoNClRoaXMgc2NlbmFy
aW8gaXMgaGFyZGVyIHdpdGhvdXQgYSBzdGFuZGFyZCB3YXkgdG8gY29tYmluZSB2ZXJpZmljYXRp
b25fdXJpIGFuZCB1c2VyX2NvZGUgaW50byBhIHNpbmdsZSBVUkkuDQoNCg0KPiBJZiB5b3UncmUg
ZG9pbmcgc29tZSBraW5kIG9mIG91dC1vZi1iYW5kIHRyYW5zbWlzc2lvbiAod2hpY2ggaXMgbWVu
dGlvbmVkIGFzIG91dCBvZiBzY29wZSBvZiB0aGUgc3BlYykgdGhlcmUncyBubyByZWFzb24geW91
IGNhbid0IHNpbXBseSB0cmFuc21pdCBib3RoIHBpZWNlcyBvZiBpbmZvcm1hdGlvbi4NCg0KTXkg
Z3Vlc3MgaXMgdGhhdCAidHJhbnNtaXR0aW5nIGJvdGggcGllY2VzIG9mIGluZm8iIHJlcXVpcmVz
IHNwZWNpYWwtcHVycG9zZSBjb2RlIHRoYXQgdW5kZXJzdGFuZHMgdGhvc2UgMiBwaWVjZXMuIFdo
ZXJlYXMgYnJvd3NpbmcgdG8gYSB0cmFuc21pdHRlZCBVUkkgaXMgZ2VuZXJpYy4NCg0KPsKgIFdl
J3ZlIGRvbmUgdGhhdCBiZWZvcmUsIGFuZCB0aGlzIGlzIHdoYXQgd2UgZG8uwqAgSGF2aW5nIHRo
ZSBkYXRhIHNlcGFyYXRlIGRpZCBub3QgcmVhbGx5IGFsdGVyIHRoZSBpbXBsZW1lbnRhdGlvbiBv
ZiB0aGlzLCBhbmQgY29tYmluaW5nIGl0IHdvdWxkbid0IG1lYXN1cmFibHkgbWFrZSBpdCBzaW1w
bGVyIChidXQgaXQgd291bGQgbWFrZSB0aGUgc3BlYyBtb3JlIGNvbXBsZXgpLg0KPg0KPiBBbHNv
IGlmIHRoZSBBUyByZWFsbHkgd2FudGVkIHRvLCB0aGVyZSdzIG5vdGhpbmcgdG8gc3RvcCBpdCBp
bmNsdWRpbmcgd2hhdGV2ZXIgcGFyYW1ldGVycyBpdCB3YW50ZWQgaW4gdGhlIHZlcmlmaWNhdGlv
biBVUkkgdG9kYXkgKHdoaWNoIGNvdWxkIGluY2x1ZGUgdGhlIHVzZXIgY29kZSkuDQoNCj4gU28g
SSdkIHByZWZlciB0byBrZWVwIDEgcHJvdG9jb2wsIGRlc2lnbmVkIGZvciB0aGUgYnJvd3NlciBt
b2RlbCAod2hpY2ggaXMgdGhlIG9ubHkgdGhpbmcgaW4tc2NvcGUgaW4gdGhlIHNwZWMpLCB0aGF0
IGNhbiBwb3RlbnRpYWxseSB3b3JrIHdpdGggYSB3aWRlIHJhbmdlIG9mIGNhc2VzLg0KDQpJdCBp
cyBzdGlsbCB0aGUgYnJvd3NlciBtb2RlbDsgaXQncyBqdXN0IGhvdyB0aGUgVVJJIGFuZCBjb2Rl
IGdldCB0byB0aGUgYnJvd3Nlci4NCg0KwqA+PiBQZXJoYXBzIGJvdGggbW9kZXMgY291bGQgYmUg
c3VwcG9ydGVkIGJ5IHNheWluZyB0aGUgdXNlcl9jb2RlIGNhbiBiZSBpbmNsdWRlZCBhcyBhIHF1
ZXJ5IHBhcmFtZXRlciBvbiB0aGUgdmVyaWZpY2F0aW9uX3VyaSB3aGVuIGl0IGlzIG1vcmUgY29u
dmVuaWVudCBmb3IgYSBkZXZpY2UgdG8gdHJhbnNtaXQgYSBzaW5nbGUgVVJJLiBBdXRob3JpemF0
aW9uIFNlcnZlcnMgTVVTVCBhY2NlcHQgdGhpcy4gVGhlIGNob2ljZSBpcyB0byB1c2UgdXNlcl9j
b2RlIGFzIHRoZSBjb21wbGV0ZSBxdWVyeSBzdHJpbmcgKGVnIGh0dHBzOi8vZXhhbXBsZS5jb20v
ZGV2aWNlP3dkamItbWpodCkgb3Igc3BlY2lmeSBhIOKAnGNvZGXigJ0gcGFyYW1ldGVyIG5hbWUg
KGVnIGh0dHBzOi8vZXhhbXBsZS5jb20vZGV2aWNlP2NvZGU9d2RqYi1tamh0KS4NCg0KPiAtMS4g
SSBrbm93IGZvciBzdXJlIEdvb2dsZSdzIEFTIHdpbGwgbm90IGNvbXBseSB3aXRoIHRoYXQgTVVT
VC4gQXMgaXQgaXMgdGhlcmUgYXJlIHNvbWUgcGhpc2hpbmcgY29uY2VybnMgYXJvdW5kIHRoaXMg
ZmxvdyAoZG9jdW1lbnRlZCBpbiB0aGUgc3BlYyksIGFuZCB0aGlzIGNoYW5nZSB1bmZvcnR1bmF0
ZWx5IG1ha2VzIHRoZSBtYXR0ZXIgd29yc2UgYnkgYWxsb3dpbmcgZm9yIHNpbmdsZS1jbGljayBw
aGlzaGluZy4NCg0KSSBkaWRuJ3QgbWVhbiB0byBpbXBseSB0aGUgQVMgaGFkIHRvICpmaW5pc2gq
IHRoZSBmbG93IGltbWVkaWF0ZWx5IHdoZW4gdXJpP2NvZGUgd2FzIGFjY2Vzc2VkLiBBbiBBUyBj
YW4gc3RpbGwgZGlzcGxheSBhbnRpLXBoaXNoaW5nIG1lYXN1cmVzIHJlcXVpcmluZyBleHBsaWNp
dCB1c2VyIGNsaWNrcyB0byBjb250aW51ZS4gVGhlIEFTIGNvdWxkIHN0aWxsIGRpc3BsYXkgYSBw
aWN0dXJlIG9mIHRoZSBkZXZpY2UuDQoNCkkgZG8gY29uY2VkZSB0aGF0IHJlcXVpcmluZyBhIGNv
ZGUgdG8gYmUgbWFudWFsbHkgZW50ZXJlZCBpcyBhIHNwZWNpZmljIHBoaXNoaW5nIGRlZmVuY2Ug
c28gYW55IGFsdGVybmF0aXZlIHNob3VsZCBwcm9iYWJseSBiZSBzcGVjaWZpZWQgc2VwYXJhdGVs
eS4NCg0KPiBGb3IgZXhhbXBsZSwgd2UgdXNlIHRoZSB0ZXh0IHRvZGF5OiAiRW50ZXIgdGhlIGNv
ZGUgZGlzcGxheWVkIG9uIHlvdXIgZGV2aWNlIi4gQW5kIHdlIGRpc3BsYXkgYSBwaWN0dXJlIHBp
Y3R1cmUgb2YgdGhlIGRldmljZSB0byBoZWxwIGd1aWRlIHRoZSB1c2VyIGFzIHRvIHRoZSBleHBl
Y3RlZCB1c2FnZSBvZiB0aGlzIGZsb3cgKHRoaXMgYnkgaXRzZWxmIGlzbid0IGV2ZXJ5dGhpbmcg
4oCTIGJ1dCB0aGV5IGFyZSBpbXBvcnRhbnQgaGludHMpLg0KDQoNCj4+IFJlY29tbWVuZGluZyBj
YXNlLWluc2Vuc2l0aXZlIHB1bmN0dWF0aW9uLWlnbm9yaW5nIGFscGhhYmV0aWMgY29kZXMgaXMg
Z29vZCwgYnV0IGhvdyBkb2VzIGEgdXNlciBrbm93IHRoaXMgaXMgdGhlIGNhc2UgZm9yIGEgcGFy
dGljdWxhciBjb2RlPyBQZXJoYXBzIHRoZSBhZHZpY2UgbmVlZHMgdG8gYmUgdG8gdXNlIGEg4oCc
ZmFuY3nigJ0gaW5wdXQgZmllbGQgd2l0aCBqYXZhc2NyaXB0IHRvIGNvbnZlcnQgdG8gdXBwZXJj
YXNlIGFzIHRoZSB1c2VyIHR5cGVzIGFuZCBoYW5kbGUgcHVuY3R1YXRpb24/DQoNCj4gSSBiZWxp
ZXZlIHRoYXQncyBjb3ZlcmVkOg0KPg0KPiAgIFRoZSBzZXJ2ZXIgc2hvdWxkIGlnbm9yZSDigKYN
Cg0KSSBndWVzcyBJIHJlYWQgdGhhdCBhcyBhIHN1Z2dlc3Rpb24gZm9yIHNlcnZlci1zaWRlIGNv
ZGUuIEJ1dCB0aGUgdXNlciBuZWVkcyBhIGhpbnQgYXQgdGhlIGNsaWVudC1zaWRlIGFzIHRoZXkg
ZW50ZXIgdGhlIGNvZGUuDQpUaGlzIGlzIGEgbWlub3IgZGV0YWlsLiBBIHdlYiBmb3JtIGNvdWxk
LCBmb3IgaW5zdGFuY2UsIHNheSAiY2FzZSBhbmQgcHVuY3R1YXRpb24gYXJlIGlnbm9yZWQiIGJl
bG93IHRoZSBjb2RlIGlucHV0IGZpZWxkLg0KwqDCoA0KLS0NCkphbWVzIE1hbmdlcg0K


From nobody Tue Feb 28 18:10:22 2017
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F7D129434; Tue, 28 Feb 2017 18:10:21 -0800 (PST)
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.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148833422136.29532.1094374422634586914.idtracker@ietfa.amsl.com>
Date: Tue, 28 Feb 2017 18:10:21 -0800
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-amr-values-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Mar 2017 02:10:21 -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 of the IETF.

        Title           : Authentication Method Reference Values
        Authors         : Michael B. Jones
                          Phil Hunt
                          Anthony Nadalin
	Filename        : draft-ietf-oauth-amr-values-06.txt
	Pages           : 15
	Date            : 2017-02-28

Abstract:
   The "amr" (Authentication Methods References) claim is defined and
   registered in the IANA "JSON Web Token Claims" registry but no
   standard Authentication Method Reference values are currently
   defined.  This specification establishes a registry for
   Authentication Method Reference values and defines an initial set of
   Authentication Method Reference values.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-amr-values-06

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


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

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


From nobody Tue Feb 28 18:16:49 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA0212943C for ; Tue, 28 Feb 2017 18:16:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_HX1wGexLY5 for ; Tue, 28 Feb 2017 18:16:45 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0107.outbound.protection.outlook.com [104.47.32.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 86463129434 for ; Tue, 28 Feb 2017 18:16:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dHl+Z1saLFYGr8CuPqaSHl5sbAmTHeAUhObLwwLn3zQ=; b=EvYjkj+VByB+H1cpGbt9Pvc9Dm9b+bBbL19GSFoQVuUIur/nudFg6lMCYATjUvXzSrNnclxm2ud8P9QV8clZCQgQQjyxbrAjTCxgQm7I9zVcy7gIjqv+3lgpB/HifijsWae0S9bbdDidBC8b/lnVvZGCyHqoyaCqLZ+RWnBrLMo=
Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.0; Wed, 1 Mar 2017 02:16:41 +0000
Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.0947.007; Wed, 1 Mar 2017 02:16:41 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: AMR Values specification addressing IESG comments
Thread-Index: AdKSLxXCKaKur3fZTruKf5zXxDifog==
Date: Wed, 1 Mar 2017 02:16:41 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.83.32]
x-ms-office365-filtering-correlation-id: c7bbbef9-4f10-4797-c120-08d460490038
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0504; 
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0504; 7:MOnL48BazZ/jZ9h+v6QlsmLedmKkPNe8O+IzCibs2oSpuo/sYZbHClhqBtzEg+IBXt2xT2ktSXi12cWf6N5jmnEGyCRT/3fyIc7JL22jkcrZEY0xIgJzzRBepU6XnxGI/OKxUou8nkdSFC/MkZy1CkwX5dw/QfwOj90bj24iixJp1nqttLYcPxTJNlA9PydkAhSz+aaUlbu5ur4fDaImbk5Z2jIpY8Rp8TKjimCHbIlPS7rmC+822NmTgTZiWyo4mi905lHEaAQS37DqoEd82zw90odCnoc82rQfVtkV+I+0GUjqUVE7ZiYvB6JskcIPRCktsNKvF5fpBx+XaF1Z93IZTjgiItPlLfQ1B7j+6rU=
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR21MB0504; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0504; 
x-forefront-prvs: 0233768B38
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(209900001)(199003)(189002)(966004)(122556002)(53936002)(110136004)(101416001)(38730400002)(53376002)(50986999)(54356999)(99286003)(54906002)(606005)(25786008)(68736007)(6916009)(5640700003)(4326008)(236005)(55016002)(92566002)(6506006)(6306002)(8666007)(54896002)(66066001)(77096006)(9686003)(5660300001)(6436002)(7696004)(2906002)(2501003)(10090500001)(5005710100001)(86612001)(3660700001)(2900100001)(5630700001)(6116002)(790700001)(102836003)(3846002)(86362001)(3280700002)(8676002)(7906003)(1730700003)(81156014)(81166006)(33656002)(7736002)(74316002)(189998001)(97736004)(10290500002)(8990500004)(8936002)(106356001)(2351001)(105586002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0504; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0504017FEF9CB7F2A9116D47F5290CY4PR21MB0504namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 02:16:41.6399 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0504
Archived-At: 
Cc: Ben Campbell , Alexey Melnikov , Jari Arkko 
Subject: [OAUTH-WG] AMR Values specification addressing IESG comments
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Mar 2017 02:16:47 -0000

--_000_CY4PR21MB0504017FEF9CB7F2A9116D47F5290CY4PR21MB0504namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The Authentication Method Reference Values specification has been updated t=
o address feedback from the IESG.  Identifiers are now restricted to using =
only printable JSON-friendly ASCII characters.  All the "amr" value definit=
ions now include specification references.

Thanks to Stephen Farrell, Alexey Melnikov, Ben Campbell, and Jari Arkko fo=
r their reviews.

The specification is available at:

  *   https://tools.ietf.org/html/draft-ietf-oauth-amr-values-06

An HTML-formatted version is also available at:

  *   http://self-issued.info/docs/draft-ietf-oauth-amr-values-06.html

                                                       -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=3D1647 and =
as @selfissued.


--_000_CY4PR21MB0504017FEF9CB7F2A9116D47F5290CY4PR21MB0504namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











The Authentication Method Reference Values specifica=
tion has been updated to address feedback from the IESG.  Identifiers =
are now restricted to using only printable JSON-friendly ASCII characters. =
 All the “am=
r”
 value definitions now include specification references.


 


Thanks to Stephen Farrell, Alexey Melnikov, Ben Camp=
bell, and Jari Arkko for their reviews.


 


The specification is available at:


    

  • <=
a href=3D"https://tools.ietf.org/html/draft-ietf-oauth-amr-values-06">https=
://tools.ietf.org/html/draft-ietf-oauth-amr-values-06
    • 

     
    

    An HTML-formatted version is also available at:=

    

      

    • <=
a href=3D"http://self-issued.info/docs/draft-ietf-oauth-amr-values-06.html"=
>http://self-issued.info/docs/draft-ietf-oauth-amr-values-06.html<=
/o:p>
    

     
    

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

     
    

    P.S.  This notice was also posted at 
http://self-issued.info/?p=3D1647 and as 
@selfissued.
    

     
    





--_000_CY4PR21MB0504017FEF9CB7F2A9116D47F5290CY4PR21MB0504namp_--


From nobody Tue Feb 28 18:17:04 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8040312947D; Tue, 28 Feb 2017 18:16:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_mi1r9_DnMR; Tue, 28 Feb 2017 18:16:56 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0126.outbound.protection.outlook.com [104.47.32.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0190F129473; Tue, 28 Feb 2017 18:16:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7yij56B/A67SKLi4+2O/jU82pm2PCKB5y7KCgsgdoe8=; b=Sv8rOTuyDRWIGOBoAvMln5kOEB3JiYu50N07EpuMkqCa9Od79iMxLVquygeVwbFVzoBa3vD/92lC6ZWJeZVyd+D6i0hD60yL345MzPPmAuUsK/pNIkrzMOoLySqVPQfNmQI8g7EnDSUTaMeyLe7Xh39vnsJI3sPAegerW+so/Cs=
Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.0; Wed, 1 Mar 2017 02:16:52 +0000
Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.0947.007; Wed, 1 Mar 2017 02:16:52 +0000
From: Mike Jones 
To: Stephen Farrell , Anthony Nadalin , joel jaeggli , The IESG 
Thread-Topic: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
Thread-Index: AQHSe97H5hXZpqeBE0CT6lHMY4yQFKFUP6sAgAABIQCAAB5D0IAAXXiAgAAdOACAAABqIIAAA2uAgAAA3wCAAAAzAIAAAO4AgAAAVZCAAAOFgIAqgOKg
Date: Wed, 1 Mar 2017 02:16:52 +0000
Message-ID: 
References: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com>    <27d6181c-eb72-b17b-ed18-db018991e44c@cs.tcd.ie>   <268ffcf0-2f90-049e-1a3c-03b39d62c338@cs.tcd.ie>     <2972e6a5-2bdb-3047-2086-271730dfc3ef@cs.tcd.ie>
In-Reply-To: <2972e6a5-2bdb-3047-2086-271730dfc3ef@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.83.32]
x-ms-office365-filtering-correlation-id: 650bfa95-f999-4902-27c9-08d4604906a0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0504; 
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0504; 7:BRwlFe/2xOT38a/jzU5/V+jjQHGRp2Aj830Chpaox1rSuD5QHbVUAAaPZQcn8SHi9xVH/AvDbQ+UBU8cr9Yh3CEAZDtu6LL0BvL81oGIJS40v+/bZfP29lvusEQDeJNWVS4bwu/+NkdKcpEKNqs+oIPPBGAhzek7gOuhJi3OnxM/AEFpw5BT8eFw4NT6lw+jKboHxQhD8nkFjv6AXmIQR6WcpvVqs2SHUsMHDEkRA1WAdjxDDrc2sufJY/2i3nqnhVpeH/zAoPDZNf67wS12tJgURXHHKvRxWCwOJ1c0b0P9nqTgkNavPCD2a96NZO8mVcolG4mbYWXEHt4tG/mR+dn84Pt6jV3w9epJz/O1npw=
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(32856632585715)(120809045254105)(21532816269658); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR21MB0504; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0504; 
x-forefront-prvs: 0233768B38
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(13464003)(40224003)(24454002)(51914003)(377454003)(199003)(189002)(966004)(122556002)(53936002)(101416001)(38730400002)(6246003)(50986999)(76176999)(54356999)(53546006)(230783001)(93886004)(2950100002)(99286003)(54906002)(25786008)(68736007)(4326008)(229853002)(55016002)(92566002)(6506006)(6306002)(1511001)(66066001)(77096006)(9686003)(5660300001)(6436002)(7696004)(2906002)(10090500001)(5005710100001)(2421001)(86612001)(3660700001)(2900100001)(6116002)(102836003)(3846002)(86362001)(3280700002)(8676002)(81156014)(81166006)(33656002)(7736002)(74316002)(551544002)(189998001)(97736004)(10290500002)(2561002)(8990500004)(106116001)(8936002)(305945005)(106356001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0504; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 02:16:52.4259 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0504
Archived-At: 
Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Mar 2017 02:16:58 -0000

SGkgU3RlcGhlbiwNCg0KRHJhZnQgLTA2IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDYgYWRkcyByZWZlcmVuY2VzIGZvciBhbGwgb2YgdGhl
IGRlZmluZWQgImFtciIgdmFsdWVzLiAgVGhhbmtzIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gaGF2
ZSBhIHRob3VnaHRmdWwgZGlzY3Vzc2lvbi4NCg0KCQkJCS0tIE1pa2UNCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFy
cmVsbEBjcy50Y2QuaWVdIA0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxLCAyMDE3IDQ6NDUg
UE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBBbnRob255
IE5hZGFsaW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT47IGpvZWwgamFlZ2dsaSA8am9lbGphQGJv
Z3VzLmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IG9hdXRoLWNoYWlyc0BpZXRm
Lm9yZzsgZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzQGlldGYub3JnOyBvYXV0aEBpZXRmLm9y
Zw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3VzcyBvbiBk
cmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6ICh3aXRoIERJU0NVU1MpDQoNCg0KDQpPbiAw
Mi8wMi8xNyAwMDozNSwgTWlrZSBKb25lcyB3cm90ZToNCj4gWW91IGNhbiBjYWxsIG1lIGxhenkg
aWYgeW91IHdhbnQuIA0KDQpJIGRvbid0IHRoaW5rIHlvdSdyZSBsYXp5Oi0pIFdlcmUgSSB0byBn
dWVzcyBJJ2QgZ3Vlc3MgdGhhdA0KaW50ZXJvcCBmb3IgdGhlc2Ugd2Fzbid0IGEgcHJpb3JpdHkg
YW5kIHRoYXQgd2UncmUgZGVmaW5pbmcNCnRoZW0gYSBiaXQgZWFybHkgYW5kIGEgbGl0dGxlIHRv
byBnZW5lcmljYWxseS4NCg0KPiBTb21lIG9mIHRoZW0gYXJlIHNvIHdlbGwga25vd24sDQo+IHN1
Y2ggYXMgInBhc3N3b3JkIiBvciAiUElOIiBpdCBkaWRuJ3Qgc2VlbSB3b3J0aHdoaWxlIHRvIHRy
eSB0byB0cmFjaw0KPiBkb3duIGEgcmVmZXJlbmNlLiANCg0KU3VyZSwgdGhvc2UgYXJlIGZpbmUu
IFRoZSBvbmx5IGlzc3VlcyB3b3VsZCBiZSBpZiB0aGVyZSdzDQphIHN0cmluZzJrZXkgZnVuY3Rp
b24gc29tZXdoZXJlIGJ1dCBJIGRvbid0IGV4cGVjdCB0aGVyZQ0KaXMgaW4gdGhpcyBjb250ZXh0
Lg0KDQo+IEJ1dCBJJ20gd2lsbGluZyB0byB3b3JrIHdpdGggb3RoZXJzIHRvIGZpbmQgZGVjZW50
DQo+IHJlZmVyZW5jZXMgZm9yIHRoZSByZXN0IG9mIHRoZW0sIGlmIHlvdSBiZWxpZXZlIHRoYXQg
d291bGQgaW1wcm92ZQ0KPiB0aGUgcXVhbGl0eSBvZiB0aGUgc3BlY2lmaWNhdGlvbi4NCg0KSSBk
byB0aGluayBpdCB3b3VsZCwgZXNwIGZvciBjYXNlcyB3aGVyZSB0aGVyZSBhcmUga25vd24NCmRp
ZmZlcmVudCBvcHRpb25zIChlLmcuIG90cCkgb3IgbGlrZWx5IGlsbC1kZWZpbmVkIG9yDQpwcm9w
cmlldGFyeSBmb3JtYXRzLiBNeSBndWVzcyBpcyB0aGF0IHNvbWUgYmlvbWV0cmljcyBmaXQNCnRo
YXQgbGF0dGVyIGJ1dCBJIGNvdWxkIGJlIHdyb25nLiBJZiB0aGV5IGRvLCB0aGVuIG9uZQ0KcnVu
cyBpbnRvIHRoZSBwcm9ibGVtIG9mIGhhdmluZyB0byBkZXBlbmQgb24gbWFnaWMgbnVtYmVycw0K
aW4gdGhlIGVuY29kaW5ncyBvciBzaW1pbGFyIHRvIGRpc3Rpbmd1aXNoIHdoaWNoIGlzIHJlYWxs
eQ0KZXJyb3IgcHJvbmUgYW5kIGxpa2VseSB0byBsZWFkIHRvIHdoYXQgb3VyIGxlYXJuZWQNCnRy
YW5zcG9ydCBjaHVtcyBhcmUgY2FsbGluZyBvc3NpZmljYXRpb247LSkNCg0KQ2hlZXJzLA0KUy4N
Cg0KDQo+IA0KPiBCZXN0IHdpc2hlcywgLS0gTWlrZQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0gRnJvbTogU3RlcGhlbiBGYXJyZWxsDQo+IFttYWlsdG86c3RlcGhlbi5mYXJyZWxs
QGNzLnRjZC5pZV0gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxLCAyMDE3DQo+IDQ6MzEgUE0g
VG86IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IEFudGhvbnkgTmFk
YWxpbg0KPiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPjsgam9lbCBqYWVnZ2xpIDxqb2VsamFAYm9n
dXMuY29tPjsgVGhlIElFU0cNCj4gPGllc2dAaWV0Zi5vcmc+IENjOiBvYXV0aC1jaGFpcnNAaWV0
Zi5vcmc7DQo+IGRyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlc0BpZXRmLm9yZzsgb2F1dGhAaWV0
Zi5vcmcgU3ViamVjdDogUmU6DQo+IFtPQVVUSC1XR10gU3RlcGhlbiBGYXJyZWxsJ3MgRGlzY3Vz
cyBvbg0KPiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6ICh3aXRoIERJU0NVU1MpDQo+
IA0KPiANCj4gDQo+IE9uIDAyLzAyLzE3IDAwOjI4LCBNaWtlIEpvbmVzIHdyb3RlOg0KPj4gVGhl
IG90aGVyIGNhc2Ugb2Yga25vd24gaW50ZXJvcCB0ZXN0aW5nIG9mICJhbXIiIHZhbHVlcyBpcyBm
b3INCj4+IE1PRFJOQSAoT3BlbklEIENvbm5lY3QgTW9iaWxlIFByb2ZpbGUpIGltcGxlbWVudGF0
aW9ucy4gIFRoZXJlJ3MgYQ0KPj4gcmVmZXJlbmNlIHRvIGl0cyB1c2Ugb2YgImFtciIgdmFsdWVz
IGluIHRoZSBzcGVjLg0KPiANCj4gWWVhaCwgaWlyYywgdGhhdCBvbmUgc2VlbWVkIG9rIChhc3N1
bWluZyB0aGUgcmVmZXJlbmNlIHRlbGxzIG1lIHdoYXQNCj4gY29kZSB0byB3cml0ZSB3aGljaCBJ
IGFzc3VtZSBpdCBkb2VzKS4NCj4gDQo+IEknbSBzdGlsbCBub3Qgc2VlaW5nIHdoeSBzb21lIGRv
IGhhdmUgc3VmZmljaWVudCByZWZlcmVuY2VzIGFuZA0KPiBvdGhlcnMgZG8gbm90Lg0KPiANCj4g
SXMgdGhlcmUgc29tZSBkaWZmaWN1bHR5IHdpdGggZmluZGluZyByZWZlcmVuY2VzIG9yIHNvbWV0
aGluZz8NCj4gDQo+IFMNCj4gDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZy
b206IEFudGhvbnkgTmFkYWxpbiBTZW50OiBXZWRuZXNkYXksIA0KPj4gRmVicnVhcnkgMSwgMjAx
NyA0OjI3IFBNIFRvOiBTdGVwaGVuIEZhcnJlbGwgDQo+PiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRj
ZC5pZT47IE1pa2UgSm9uZXMgDQo+PiA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgam9l
bCBqYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPjsNCj4+IFRoZSBJRVNHIDxpZXNnQGlldGYub3Jn
PiBDYzogb2F1dGgtY2hhaXJzQGlldGYub3JnOyANCj4+IGRyYWZ0LWlldGYtb2F1dGgtYW1yLXZh
bHVlc0BpZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmcgU3ViamVjdDogUkU6IA0KPj4gW09BVVRILVdH
XSBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIG9uIA0KPj4gZHJhZnQtaWV0Zi1vYXV0aC1hbXIt
dmFsdWVzLTA1OiAod2l0aCBESVNDVVNTKQ0KPj4gDQo+PiBXZSBoYXZlIGludGVyb3BlZCBiZXR3
ZWVuIEZJRE8gYXV0aGVudGljYXRvcnMgdmVuZG9ycyBhbmQgV2luZG93cyANCj4+IEhlbGxvDQo+
PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IFN0ZXBoZW4gRmFycmVsbCAN
Cj4+IFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gU2VudDogV2VkbmVzZGF5LCBG
ZWJydWFyeSAxLA0KPj4gMjAxNyA0OjI0IFBNIFRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVz
QG1pY3Jvc29mdC5jb20+OyBBbnRob255DQo+PiBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5j
b20+OyBqb2VsIGphZWdnbGkgPGpvZWxqYUBib2d1cy5jb20+Ow0KPj4gVGhlIElFU0cgPGllc2dA
aWV0Zi5vcmc+IENjOiBvYXV0aC1jaGFpcnNAaWV0Zi5vcmc7IA0KPj4gZHJhZnQtaWV0Zi1vYXV0
aC1hbXItdmFsdWVzQGlldGYub3JnOyBvYXV0aEBpZXRmLm9yZyBTdWJqZWN0OiBSZTogDQo+PiBb
T0FVVEgtV0ddIFN0ZXBoZW4gRmFycmVsbCdzIERpc2N1c3Mgb24gDQo+PiBkcmFmdC1pZXRmLW9h
dXRoLWFtci12YWx1ZXMtMDU6ICh3aXRoIERJU0NVU1MpDQo+PiANCj4+IA0KPj4gDQo+PiBPbiAw
Mi8wMi8xNyAwMDoyMSwgTWlrZSBKb25lcyB3cm90ZToNCj4+PiBUaGFua3MsIFRvbnkuICBJIGNh
biBhZGQgdGhhdCByZWZlcmVuY2UuDQo+Pj4gDQo+Pj4gU3RlcGhlbiwgdGhlIHNldHMgb2YgaW5p
dGlhbCB2YWx1ZXMgd2VyZSBjaG9zZW4gZnJvbSB0aG9zZSB1c2VkDQo+Pj4gaW4gcHJhY3RpY2Ug
YnkgTWljcm9zb2Z0IGFuZCBHb29nbGUgaW4gcmVhbCBkZXBsb3ltZW50cy4NCj4+IA0KPj4gR2Vu
dWluZSBxdWVzdGlvbnM6IGRvIHlvdSBhaW0gdG8gaGF2ZSBpbnRlcm9wIGJldHdlZW4gdGhvc2Ug
DQo+PiBkZXBsb3ltZW50cz8gV2hhdCBpZiBJIHdhbnRlZCB0byB3cml0ZSBjb2RlIHRoYXQnZCBp
bnRlcm9wIHdpdGgNCj4+IG1zZnQgb3IgZ29vZ2xlPw0KPj4gDQo+PiBTLg0KPj4gDQo+Pj4gDQo+
Pj4gQWJvdXQgIm90cCIsIHRoZXJlIGFyZSBleGlzdGluZyB1c2UgY2FzZXMgZm9yIGluZGljYXRp
bmcgdGhhdCBhbiANCj4+PiBPVFAgd2FzIHVzZWQuICBJJ20gbm90IGF3YXJlIG9mIGFueSBvZiB0
aGVzZSB1c2UgY2FzZXMgd2hlcmUgdGhlDQo+Pj4gIGRpc3RpbmN0aW9uIGJldHdlZW4gVE9UUCBh
bmQgSE9UUCBpcyBpbXBvcnRhbnQuICBUaHVzLCBoYXZpbmcgDQo+Pj4gIm90cCIgbm93IG1ha2Vz
IHNlbnNlLCB3aGVyZSBoYXZpbmcgImhvdHAiIGFuZCAidG90cCIgbm93DQo+Pj4gZG9lc24ndC4N
Cj4+PiANCj4+PiBTdGVwaGVuLCB0aGlzIG1heSBzZWVtIGxpa2Ugc3BsaXR0aW5nIGhhaXJzLCBi
dXQgdGhlIHJlZ2lzdHJ5IA0KPj4+IGluc3RydWN0aW9ucyBmb3IgIlNwZWNpZmljYXRpb24gRG9j
dW1lbnQocykiIGFyZSBhYm91dCBoYXZpbmcgYSANCj4+PiByZWZlcmVuY2UgZm9yIHRoZSBkb2N1
bWVudCB3aGVyZSB0aGUgQXV0aGVudGljYXRpb24gTWV0aG9kIA0KPj4+IFJlZmVyZW5jZSBOYW1l
IChzdWNoIGFzICJvdHAiKSBpcyBkZWZpbmVkLiAgSW4gYWxsIGNhc2VzIGZvciB0aGUgDQo+Pj4g
aW5pdGlhbCB2YWx1ZXMsIHRoaXMgaXMgdGhlIFJGQy10by1iZSwgc28gdGhlIHJlZ2lzdHJ5DQo+
Pj4gaW5zdHJ1Y3Rpb25zIGFyZSBzYXRpc2ZpZWQuICBJZiBzb21lb25lIHdlcmUsIGZvciBpbnN0
YW5jZSwgdG8NCj4+PiBkZWZpbmUgdGhlIHN0cmluZyAiaG90cCIsIGl0IHdvdWxkIGJlIGluY3Vt
YmVudCBvbiB0aGUgcGVyc29uDQo+Pj4gcmVxdWVzdGluZyBpdHMgcmVnaXN0cmF0aW9uIHRvIHBy
b3ZpZGUgYSBVUkwgdG8gdGhlIGRvY3VtZW50DQo+Pj4gd2hlcmUgdGhlIHN0cmluZyAiaG90cCIg
aXMgZGVmaW5lZC4gIEFsc28gaGF2aW5nIGEgcmVmZXJlbmNlIHRvDQo+Pj4gUkZDIDQyMjYgaW4g
dGhhdCBkb2N1bWVudCB3b3VsZCBiZSBhIGdvb2QgdGhpbmcsIGJ1dCB0aGF0IGlzbid0DQo+Pj4g
d2hhdCB0aGUgcmVnaXN0cnkgaW5zdHJ1Y3Rpb25zIGFyZSBhYm91dC4NCj4+PiANCj4+PiBBbGwg
dGhhdCBzYWlkLCBJIGNhbiBsb29rIGF0IGFsc28gZmluZGluZyBhcHByb3ByaWF0ZSByZWZlcmVu
Y2VzIA0KPj4+IGZvciB0aGUgcmVtYWluaW5nIHZhbHVlcyB0aGF0IGRvbid0IGN1cnJlbnRseSBo
YXZlIHRoZW0uDQo+Pj4gKEFueW9uZSBnb3QgYSBnb29kIHJlZmVyZW5jZSBmb3IgcGFzc3dvcmQg
b3IgUElOIHRvIHN1Z2dlc3QsIGZvciANCj4+PiBpbnN0YW5jZT8pDQo+Pj4gDQo+Pj4gLS0gTWlr
ZQ0KPj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IEFudGhvbnkgTmFk
YWxpbiBTZW50OiBXZWRuZXNkYXksDQo+Pj4gIEZlYnJ1YXJ5IDEsIDIwMTcgNDoxMCBQTSBUbzog
U3RlcGhlbiBGYXJyZWxsIA0KPj4+IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPjsgTWlrZSBK
b25lcyANCj4+PiA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgam9lbCBqYWVnZ2xpIDxq
b2VsamFAYm9ndXMuY29tPjsgDQo+Pj4gVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+IENjOiBvYXV0
aC1jaGFpcnNAaWV0Zi5vcmc7IA0KPj4+IGRyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlc0BpZXRm
Lm9yZzsgb2F1dGhAaWV0Zi5vcmcgU3ViamVjdDogUkU6DQo+Pj4gIFtPQVVUSC1XR10gU3RlcGhl
biBGYXJyZWxsJ3MgRGlzY3VzcyBvbiANCj4+PiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMt
MDU6ICh3aXRoIERJU0NVU1MpDQo+Pj4gDQo+Pj4gTklTVCBhc2tlZCBmb3IgdGhlIGFkZGl0aW9u
IG9mIElSSVMgKGFzIHRoZXkgYXJlIHNlZWluZyBtb3JlIHVzZSANCj4+PiBvZiBJUklTIG92ZXIg
cmV0aW5hIGR1ZSB0byB0aGUgYWNjdXJhY3kgb2YgaXJpcykgIGFzIHRoZXkgaGF2ZSANCj4+PiBi
ZWVuIGRvaW5nIHNpZ25pZmljYW50IHRlc3Rpbmcgb24gdmFyaW91cyBpcmlzIGRldmljZXMgYW5k
DQo+Pj4gY29udGludWUgdG8gZG8gc28sIGhlcmUgaXMgYSByZXBvcnQgdGhhdCBOSVNUIHJlbGVh
c2VkIA0KPj4+IGh0dHA6Ly8yMDEwLTIwMTQuY29tbWVyY2UuZ292L2Jsb2cvMjAxMi8wNC8yMy9u
aXN0LWlyaXMtcmVjb2duaXRpb24tcmVwb3J0LWV2YWx1YXRlcy1uZWVkbGUtaGF5c3RhY2stc2Vh
cmNoLWNhcGFiaWxpdHkuaHRtbA0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+DQo+Pj4gDQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBTdGVwaGVuIEZhcnJlbGwNCj4+PiBbbWFpbHRvOnN0
ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdIFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMSwgDQo+
Pj4gMjAxNyAyOjI2IFBNIFRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j
b20+OyBqb2VsIA0KPj4+IGphZWdnbGkgPGpvZWxqYUBib2d1cy5jb20+OyBUaGUgSUVTRyA8aWVz
Z0BpZXRmLm9yZz4gQ2M6IA0KPj4+IG9hdXRoLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1v
YXV0aC1hbXItdmFsdWVzQGlldGYub3JnOyANCj4+PiBvYXV0aEBpZXRmLm9yZyBTdWJqZWN0OiBS
ZTogW09BVVRILVdHXSBTdGVwaGVuIEZhcnJlbGwncyBEaXNjdXNzIA0KPj4+IG9uIGRyYWZ0LWll
dGYtb2F1dGgtYW1yLXZhbHVlcy0wNTogKHdpdGggRElTQ1VTUykNCj4+PiANCj4+PiANCj4+PiBI
aSBNaWtlLA0KPj4+IA0KPj4+IE9uIDAxLzAyLzE3IDE3OjAwLCBNaWtlIEpvbmVzIHdyb3RlOg0K
Pj4+PiBUaGFua3MgZm9yIHRoZSBkaXNjdXNzaW9uLCBTdGVwaGVuLg0KPj4+PiANCj4+Pj4gVG8g
eW91ciBwb2ludCBhYm91dCAib3RwIiwgdGhlIHdvcmtpbmcgZ3JvdXAgZGlzY3Vzc2VkIHRoaXMN
Cj4+Pj4gdmVyeSBwb2ludC4gIFRoZXkgZXhwbGljaXRseSBkZWNpZGVkIG5vdCB0byBpbnRyb2R1
Y2UgImhvdHAiDQo+Pj4+IGFuZCAidG90cCIgaWRlbnRpZmllcnMgYmVjYXVzZSBubyBvbmUgaGFk
IGEgdXNlIGNhc2UgaW4gd2hpY2gNCj4+Pj4gdGhlIGRpc3RpbmN0aW9uIG1hdHRlcmVkLg0KPj4+
IA0KPj4+IFRoZW4gSSdtIG5vdCBmb2xsb3dpbmcgd2h5IGFkZGluZyAib3RwIiB0byB0aGUgcmVn
aXN0cnkgbm93IGlzIGEgDQo+Pj4gZ29vZCBwbGFuLg0KPj4+IA0KPj4+IElmIHRoZXJlJ3MgYSB1
c2UtY2FzZSBub3csIHRoZW4gYWRkaW5nIGFuIGVudHJ5IHdpdGggYSBnb29kIA0KPj4+IHJlZmVy
ZW5jZSB0byB0aGUgcmVsZXZhbnQgc3BlYyBzZWVtcyByaWdodC4NCj4+PiANCj4+PiBJZiB0aGVy
ZSdzIG5vIHVzZS1jYXNlIG5vdywgdGhlbiBub3QgYWRkaW5nIGl0IHRvIHRoZSByZWdpc3RyeSAN
Cj4+PiBzZWVtcyByaWdodC4gKE1lbnRpb25pbmcgaXQgYXMgYSBwb3NzaWJsZSBmdXR1cmUgZW50
cnkgd291bGQgYmUgDQo+Pj4gZmluZS4pDQo+Pj4gDQo+Pj4gSSB0aGluayB0aGUgc2FtZSBsb2dp
YyB3b3VsZCBhcHBseSBmb3IgYWxsIHRoZSB2YWx1ZXMgdGhhdCB0aGlzIA0KPj4+IHNwZWMgYWRk
cyB0byB0aGUgcmVnaXN0cnkuIFdoeSBpcyB0aGF0IHdyb25nPw0KPj4+IA0KPj4+PiBPdGhlcnMg
Y2FuIGNlcnRhaW5seSBpbnRyb2R1Y2UgdGhvc2UgaWRlbnRpZmllcnMgYW5kIHJlZ2lzdGVyIA0K
Pj4+PiB0aGVtIGlmIHRoZXkgZG8gaGF2ZSBzdWNoIGEgdXNlIGNhc2UsIG9uY2UgdGhlIHJlZ2lz
dHJ5IGhhcw0KPj4+PiBiZWVuIGVzdGFibGlzaGVkLiAgQnV0IHRoZSB3b3JraW5nIGdyb3VwIHdh
bnRlZCB0byBiZQ0KPj4+PiBjb25zZXJ2YXRpdmUgYWJvdXQgdGhlIGlkZW50aWZpZXJzIGludHJv
ZHVjZWQgdG8gcHJpbWUgdGhlDQo+Pj4+IHJlZ2lzdHJ5LCBhbmQgdGhpcyBpcyBzdWNoIGEgY2Fz
ZS4NCj4+Pj4gDQo+Pj4+IFdoYXQgaWRlbnRpZmllcnMgdG8gdXNlIGFuZCByZWdpc3RlciB3aWxs
IGFsd2F5cyBiZSBhIGJhbGFuY2luZw0KPj4+PiAgYWN0LiBZb3Ugd2FudCB0byBiZSBhcyBzcGVj
aWZpYyBhcyBuZWNlc3NhcnkgdG8gYWRkIHByYWN0aWNhbCANCj4+Pj4gYW5kIHVzYWJsZSB2YWx1
ZSwgYnV0IG5vdCBzbyBzcGVjaWZpYyBhcyB0byBtYWtlIHRoaW5ncyANCj4+Pj4gdW5uZWNlc3Nh
cmlseSBicml0dGxlLg0KPj4+IA0KPj4+IEVoLi4uIGRvbid0IHdlIHdhbnQgaW50ZXJvcD8gSXNu
J3QgdGhhdCB0aGUgcHJpbWFyeSBnb2FsIGhlcmU/DQo+Pj4gDQo+Pj4+IFdoaWxlIHNvbWUgbWln
aHQgc2F5IHRoZXJlJ3MgYSBkaWZmZXJlbmNlIGJldHdlZW4gc2VyaWFsIG51bWJlcg0KPj4+PiAg
cmFuZ2VzIG9mIHBhcnRpY3VsYXIgYXV0aGVudGljYXRpb24gZGV2aWNlcywgZ29pbmcgdGhlcmUg
aXMgDQo+Pj4+IGNsZWFybHkgaW4gdGhlIHdlZWRzLiAgT24gdGhlIG90aGVyIGhhbmQsIHdoaWxl
IHRoZXJlIHVzZWQgdG8NCj4+Pj4gYmUgYW4gImV5ZSIgaWRlbnRpZmllciwgRWxhaW5lIE5ld3Rv
biBvZiBOSVNUIHBvaW50ZWQgb3V0IHRoYXQNCj4+Pj4gdGhlcmUgYXJlIHNpZ25pZmljYW50IGRp
ZmZlcmVuY2VzIGJldHdlZW4gcmV0aW5hIGFuZCBpcmlzDQo+Pj4+IG1hdGNoaW5nLCBzbyAiZXll
IiB3YXMgcmVwbGFjZWQgd2l0aCAicmV0aW5hIiBhbmQgImlyaXMiLg0KPj4+PiBDb21tb24gc2Vu
c2UgaW5mb3JtZWQgYnkgYWN0dWFsIGRhdGEgaXMgdGhlIGtleSBoZXJlLg0KPj4+IA0KPj4+IFRo
YXQncyBhbm90aGVyIGdvb2QgZXhhbXBsZS4gVGhlcmUncyBubyByZWZlcmVuY2UgZm9yICJpcmlz
LiIgSWYgDQo+Pj4gdGhhdCBpcyB1c2VkIGluIHNvbWUgcHJvdG9jb2wsIHRoZW4gd2hhdCBmb3Jt
YXQocykgYXJlIGV4cGVjdGVkDQo+Pj4gdG8gYmUgc3VwcG9ydGVkPyBXaGVyZSBkbyBJIGZpbmQg
dGhhdCBzcGVjPyBJZiB3ZSBjYW4gYW5zd2VyDQo+Pj4gdGhhdCwgdGhlbiBncmVhdCwgbGV0J3Mg
YWRkIHRoZSBkZXRhaWxzLiBJZiBub3QsIHRoZW4gSSdkIHN1Z2dlc3QNCj4+PiB3ZSBvbWl0ICJp
cmlzIiBhbmQgbGVhdmUgaXQgJ3RpbGwgbGF0ZXIgdG8gYWRkIGFuIGVudHJ5IGZvciB0aGF0Lg0K
Pj4+IEFuZCBhZ2FpbiwgaW5jbHVkaW5nIHRleHQgd2l0aCAiaXJpcyIgYXMgYW4gZXhhbXBsZSBp
cyBqdXN0IGZpbmUsDQo+Pj4gYWxsIEknbSBhc2tpbmcgaXMgdGhhdCB3ZSBvbmx5IGFkZCB0aGUg
cmVnaXN0cnkgZW50cnkgaWYgd2UgY2FuDQo+Pj4gbWVldCB0aGUgc2FtZSBiYXIgdGhhdCB3ZSdy
ZSBhc2tpbmcgdGhlIERFIHRvIGltcG9zZSBvbiBsYXRlciANCj4+PiBhZGRpdGlvbnMuDQo+Pj4g
DQo+Pj4gQW5kIHRoZSBzYW1lIGZvciBhbGwgdGhlIG90aGVycy4uLg0KPj4+IA0KPj4+IENoZWVy
cywgUy4NCj4+PiANCj4+PiANCj4+Pj4gDQo+Pj4+IFRoZSBwb2ludCBvZiB0aGUgcmVnaXN0cnkg
cmVxdWlyaW5nIGEgc3BlY2lmaWNhdGlvbiByZWZlcmVuY2UNCj4+Pj4gaXMgc28gcGVvcGxlIHVz
aW5nIHRoZSByZWdpc3RyeSBjYW4gdGVsbCB3aGVyZSB0aGUgaWRlbnRpZmllcg0KPj4+PiBpcyBk
ZWZpbmVkLiBGb3IgYWxsIHRoZSBpbml0aWFsIHZhbHVlcywgdGhhdCByZXF1aXJlbWVudCBpcyAN
Cj4+Pj4gc2F0aXNmaWVkLCBzaW5jZSB0aGUgcmVmZXJlbmNlIHdpbGwgYmUgdG8gdGhlIG5ldyBS
RkMuICBJDQo+Pj4+IHRoaW5rIHRoYXQgYWxpZ25zIHdpdGggdGhlIHBvaW50IHRoYXQgSm9lbCB3
YXMgbWFraW5nLg0KPj4+PiANCj4+Pj4gWW91ciB0aG91Z2h0cz8NCj4+Pj4gDQo+Pj4+IC0tIE1p
a2UNCj4+Pj4gDQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IE9BdXRoIA0K
Pj4+PiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVu
IEZhcnJlbGwgDQo+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMSwgMjAxNyA3OjAzIEFN
IFRvOiBqb2VsIGphZWdnbGkgDQo+Pj4+IDxqb2VsamFAYm9ndXMuY29tPjsgVGhlIElFU0cgPGll
c2dAaWV0Zi5vcmc+IENjOiANCj4+Pj4gb2F1dGgtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRm
LW9hdXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7IA0KPj4+PiBvYXV0aEBpZXRmLm9yZyBTdWJqZWN0
OiBSZTogW09BVVRILVdHXSBTdGVwaGVuIEZhcnJlbGwncw0KPj4+PiBEaXNjdXNzIG9uIGRyYWZ0
LWlldGYtb2F1dGgtYW1yLXZhbHVlcy0wNTogKHdpdGggRElTQ1VTUykNCj4+Pj4gDQo+Pj4+IA0K
Pj4+PiANCj4+Pj4gT24gMDEvMDIvMTcgMTQ6NTgsIGpvZWwgamFlZ2dsaSB3cm90ZToNCj4+Pj4+
IE9uIDEvMzEvMTcgODoyNiBBTSwgU3RlcGhlbiBGYXJyZWxsIHdyb3RlOg0KPj4+Pj4+IFN0ZXBo
ZW4gRmFycmVsbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbg0KPj4+
Pj4+IGZvciBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXMtMDU6IERpc2N1c3MNCj4+Pj4+PiAN
Cj4+Pj4+PiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50
YWN0IGFuZCANCj4+Pj4+PiByZXBseSB0byBhbGwgZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGlu
IHRoZSBUbyBhbmQgQ0MNCj4+Pj4+PiBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRy
b2R1Y3RvcnkgcGFyYWdyYXBoLA0KPj4+Pj4+IGhvd2V2ZXIuKQ0KPj4+Pj4+IA0KPj4+Pj4+IA0K
Pj4+Pj4+IFBsZWFzZSByZWZlciB0byANCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNn
L3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4+Pj4+PiBmb3IgbW9yZSBpbmZvcm1h
dGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQNCj4+Pj4+PiBwb3NpdGlvbnMuDQo+
Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJh
bGxvdCBwb3NpdGlvbnMsIGNhbiBiZQ0KPj4+Pj4+IGZvdW5kIGhlcmU6IA0KPj4+Pj4+IGh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtYW1yLXZhbHVlcy8N
Cj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+DQo+Pj4+Pj4gDQotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCj4+Pj4+PiANCj4+Pj4+PiANCj4+PiANCj4+Pj4+PiANCj4+IC0NCj4+Pj4+PiBE
SVNDVVNTOiANCj4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4NCj4+Pj4+
Pg0KPj4NCj4+Pj4+Pg0KPg0KPj4+Pj4+IA0KLQ0KPj4+Pj4+IA0KPj4+Pj4+IFRoaXMgc3BlY2lm
aWNhdGlvbiBzZWVtcyB0byBtZSB0byBicmVhayBpdCdzIG93biBydWxlcy4gWW91DQo+Pj4+Pj4g
IHN0YXRlIHRoYXQgcmVnaXN0cmF0aW9ucyBzaG91bGQgaW5jbHVkZSBhIHJlZmVyZW5jZSB0byBh
IA0KPj4+Pj4+IHNwZWNpZmljYXRpb24gdG8gaW1wcm92ZSBpbnRlcm9wLiBBbmQgeWV0LCBmb3Ig
dGhlIHN0cmluZ3MNCj4+Pj4+PiAgYWRkZWQgaGVyZSAoZS5nLiBvdHApIHlvdSBkb24ndCBkbyB0
aGF0IChyZWZlcnJpbmcgdG8NCj4+Pj4+PiBzZWN0aW9uIDIgd2lsbCBub3QgaW1wcm92ZSBpbnRl
cm9wKSBhbmQgdGhlcmUgYXJlIGRpZmZlcmVudA0KPj4+Pj4+IHdheXMgaW4gd2hpY2ggbWFueSBv
ZiB0aGUgbWV0aG9kcyBpbiBzZWN0aW9uIDIgY2FuIGJlIGRvbmUuDQo+Pj4+Pj4gU28gSSB0aGlu
ayB5b3UgbmVlZCB0byBhZGQgYSBidW5jaCBtb3JlIHJlZmVyZW5jZXMuDQo+Pj4+PiANCj4+Pj4+
IE5vdCBjbGVhciB0byBtZSB0aGF0IHRoZSBkb2N1bWVudCBjcmVhdGluZyB0aGUgcmVnaXN0cnkN
Cj4+Pj4+IG5lZWRzIHRvIGFkaGVyZSB0byB0aGUgcnVsZXMgZm9yIGZ1cnRoZXIgYWxsb2NhdGlv
bnMgaW4gb3JkZXINCj4+Pj4+IHRvIHByZXBvdWxhdGUgdGhlIHJlZ2lzdHJ5LiB0aGF0IGlzIHBl
cmhhcHMgYW4gYXBwZWFsIHRvDQo+Pj4+PiBmdXR1cmUgY29uc2lzdGVuY3kuDQo+Pj4+IA0KPj4+
PiBTdXJlIC0gSSdtIGFsbCBmb3IgYSBzbWF0dGVyaW5nIG9mIGluY29uc2lzdGVuY3k6LSkNCj4+
Pj4gDQo+Pj4+IEJ1dCBJIHRoaW5rIHRoZSBsYWNrIG9mIHNwZWNzIGluIHNvbWUgb2YgdGhlc2Ug
Y2FzZXMgY291bGQgDQo+Pj4+IGltcGFjdCBvbiBpbnRlcm9wLCBlLmcuIGluIHRoZSBvdHAgY2Fz
ZSwgdGhleSBxdW90ZSB0d28gUkZDcw0KPj4+PiBhbmQgeWV0IG9ubHkgaGF2ZSBvbmUgdmFsdWUu
IFRoYXQgc2VlbXMgYSBiaXQgYnJva2VuIHRvIG1lLCBzbw0KPj4+PiB0aGUgZGlzY3VzcyBpc24n
dCByZWFsbHkgYWJvdXQgdGhlIGZvcm1hbGlzbS4NCj4+Pj4gDQo+Pj4+IFMuDQo+Pj4+IA0KPj4+
PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+IA0KPj4+
IA0KPj4gDQo+IA0KDQo=


From nobody Tue Feb 28 18:17:39 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD6D129470; Tue, 28 Feb 2017 18:17:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.011
X-Spam-Level: 
X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PsM2d7CB1lF; Tue, 28 Feb 2017 18:17:18 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0101.outbound.protection.outlook.com [104.47.32.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4483D12978C; Tue, 28 Feb 2017 18:17:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cT/HoYjmyaDO98r8qlk2y2wtSu+/Yzhgo5XpN2QAXek=; b=S3MpII6ZmdnP8Mt6fQz5fMFmGcZd2QKYYqKg05y/wlVByQZnyHq91LCa1+ceWQnQ1gmV60rZeEDPDyVxFA803AyK8ju37ZpDCrYNTf9IGzjvbVI5O2eN/4y8MpL2jPTet8cqou+YsC50e9Vtp/rLuEArzHhVUgL2zT1nJAZ7+wc=
Received: from CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) by CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.0; Wed, 1 Mar 2017 02:17:08 +0000
Received: from CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) by CY4PR21MB0504.namprd21.prod.outlook.com ([10.172.122.14]) with mapi id 15.01.0947.007; Wed, 1 Mar 2017 02:17:08 +0000
From: Mike Jones 
To: Alexey Melnikov , The IESG 
Thread-Topic: Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT)
Thread-Index: AQHSfSstZ8gA/avhoUyAuPTivWAUwqFV0P+QgAAArYCAADBacIABELoAgChOIqA=
Date: Wed, 1 Mar 2017 02:17:07 +0000
Message-ID: 
References: <148602274618.28299.16863291767893795433.idtracker@ietfa.amsl.com>  <1486048021.331167.868093568.44D5380B@webmail.messagingengine.com>  <1486116972.569299.869047696.03427CD3@webmail.messagingengine.com>
In-Reply-To: <1486116972.569299.869047696.03427CD3@webmail.messagingengine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.83.32]
x-ms-office365-filtering-correlation-id: 36c28147-e168-4e9c-f970-08d460490fcf
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0504; 
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0504; 7:1Tt+jHQfZAwLfEwR1qhocLOTo3PvxAfCi/D4GNz9I7Qp0I9HsoIaNlVFAx7DQneexCzJ90+swdoSIOtZgcqcznZY6YSJO4sn8Us9WI26+/ueEHM+qbLTtteyrBG/VHDWLMyLOGp4XejUpw9XAuPPKjxw2ZgERUm8FhzhoE5SUHV7YvTj22nKg62T7gbI7rPlYvgoTrz3oflGZW4GcTinPJtj++rhFNKw7UU5iC7kHR1LxXAEh/m9H29Q95xYrAGZXczS3CbBvxyGRld9NzX6bqabq4dlV3UJladCRnhEM5T9nvfTrT19WlUm6gZEE8SZ9ucZTDVL2J4QHGIGOsxLs7xw5DPfptv+yBymUecSZSI=
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105)(131327999870524)(248736688235697); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:CY4PR21MB0504; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0504; 
x-forefront-prvs: 0233768B38
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39850400002)(39410400002)(39450400003)(13464003)(24454002)(377454003)(199003)(43784003)(51444003)(189002)(122556002)(53936002)(101416001)(38730400002)(6246003)(50986999)(76176999)(54356999)(53546006)(230783001)(93886004)(2950100002)(99286003)(54906002)(25786008)(68736007)(4326008)(229853002)(55016002)(92566002)(6506006)(6306002)(8666007)(66066001)(77096006)(9686003)(5660300001)(6436002)(7696004)(2906002)(10090500001)(5005710100001)(86612001)(3660700001)(2900100001)(6116002)(102836003)(3846002)(86362001)(3280700002)(8676002)(81156014)(81166006)(33656002)(7736002)(74316002)(189998001)(97736004)(10290500002)(8990500004)(106116001)(8936002)(305945005)(106356001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0504; H:CY4PR21MB0504.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 02:17:07.7797 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0504
Archived-At: 
Cc: "oauth-chairs@ietf.org" , "draft-ietf-oauth-amr-values@ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Mar 2017 02:17:33 -0000

SGkgQWxleGV5LA0KDQpEcmFmdCAtMDYgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtb2F1dGgtYW1yLXZhbHVlcy0wNiByZXN0cmljdHMgdGhlIGNoYXJhY3RlciBzZXQgdG8g
dGhlIHByaW50ZWQgc3Vic2V0IG9mIEFTQ0lJIHByZXZpb3VzbHkgZGlzY3Vzc2VkLiAgSXQgYWxz
byBhZGRyZXNzZXMgdGhlIHJlYWRhYmlsaXR5IGNvbmNlcm4geW91IHJhaXNlZC4gIEZpbmFsbHks
IGl0IGFkZHMgcmVmZXJlbmNlcyB0byBhZGRyZXNzIFN0ZXBoZW4ncyBwb2ludC4NCg0KVGhhbmtz
IGFnYWluIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcHJvZHVjZSB5b3VyIHVzZWZ1bCByZXZpZXcu
DQoNCgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbGV4
ZXkgTWVsbmlrb3YgW21haWx0bzphYW1lbG5pa292QGZhc3RtYWlsLmZtXSANClNlbnQ6IEZyaWRh
eSwgRmVicnVhcnkgMywgMjAxNyAyOjE2IEFNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25l
c0BtaWNyb3NvZnQuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpDYzogZHJhZnQtaWV0
Zi1vYXV0aC1hbXItdmFsdWVzQGlldGYub3JnOyBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRz
Y2hvZmVuaWdAZ214Lm5ldD47IG9hdXRoLWNoYWlyc0BpZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmcN
ClN1YmplY3Q6IFJlOiBBbGV4ZXkgTWVsbmlrb3YncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtb2F1
dGgtYW1yLXZhbHVlcy0wNTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KT24gVGh1LCBG
ZWIgMiwgMjAxNywgYXQgMDY6MDUgUE0sIE1pa2UgSm9uZXMgd3JvdGU6DQo+IEkgd2FzIHBsYW5u
aW5nIHRvIHN0YXkgd2l0aCB0aGUgY2hhcmFjdGVycyBzcGVjaWZpZWQgaW4gNi4xIChhKQ0KPiBo
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTA1
I3NlY3Rpb24tNi4xOg0KPiANCj4gICAgYS4gIHJlcXVpcmUgdGhhdCBBdXRoZW50aWNhdGlvbiBN
ZXRob2QgUmVmZXJlbmNlIHZhbHVlcyBiZWluZw0KPiAgICAgICAgcmVnaXN0ZXJlZCB1c2Ugb25s
eSBwcmludGFibGUgQVNDSUkgY2hhcmFjdGVycyBleGNsdWRpbmcgZG91YmxlDQo+ICAgICAgICBx
dW90ZSAoJyInKSBhbmQgYmFja3NsYXNoICgnXCcpICh0aGUgVW5pY29kZSBjaGFyYWN0ZXJzIHdp
dGggY29kZQ0KPiAgICAgICAgcG9pbnRzIFUrMDAyMSwgVSswMDIzIHRocm91Z2ggVSswMDVCLCBh
bmQgVSswMDVEIHRocm91Z2ggDQo+IFUrMDA3RSksDQo+IA0KPiBUaGF0IGV4Y2x1ZGVzIHNwYWNl
LiAgVGhhdCdzIHRoZSBzZXQgdGFrZW4gZnJvbSBSRkMgNzYzOCwgU2VjdGlvbiA2IA0KPiBodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzYzOCNzZWN0aW9uLTYsIHdoaWNoIGlzIGEgdmVy
eSByZWxhdGVkIA0KPiB1c2FnZS4NCj4gDQo+IFNwYWNlIGlzIGV4Y2x1ZGVkIGJlY2F1c2Ugc29t
ZXRpbWVzIGluIE9BdXRoIG1lc3NhZ2VzLCB2YWx1ZXMgYXJlIA0KPiByZXByZXNlbnRlZCBhcyBz
cGFjZS1zZXBhcmF0ZWQgc3RyaW5ncy4NCg0KSSBhbSBzb3JyeSBJIG1pc3JlYWQgdGhpcyBlYXJs
aWVyOiB5b3UgYWxyZWFkeSBleGNsdWRlIHNwYWNlLCBzbyB0aGUgdGV4dCBhcyBzcGVjaWZpZWQg
aXMgZmluZS4NCg0KPiAJCQkJLS0gTWlrZQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gRnJvbTogQWxleGV5IE1lbG5pa292IFttYWlsdG86YWFtZWxuaWtvdkBmYXN0bWFpbC5m
bV0NCj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIsIDIwMTcgNzowNyBBTQ0KPiBUbzogTWlr
ZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0
Zi5vcmc+DQo+IENjOiBkcmFmdC1pZXRmLW9hdXRoLWFtci12YWx1ZXNAaWV0Zi5vcmc7IEhhbm5l
cyBUc2Nob2ZlbmlnIA0KPiA8SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldD47IG9hdXRoLWNoYWly
c0BpZXRmLm9yZzsgb2F1dGhAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IEFsZXhleSBNZWxuaWtv
didzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTA1Og0KPiAod2l0aCBE
SVNDVVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gSGkgTWlrZSwNCj4gDQo+IE9uIFRodSwgRmViIDIs
IDIwMTcsIGF0IDAzOjA1IFBNLCBNaWtlIEpvbmVzIHdyb3RlOg0KPiA+IEknZCBiZSBPSyBsaW1p
dGluZyB0aGUgcHJvdG9jb2wgZWxlbWVudHMgdG8gdXNpbmcgQVNDSUkgY2hhcmFjdGVycywgDQo+
ID4gaWYgdGhhdCB3b3VsZCBiZSB0aGUgSUVTRydzIHByZWZlcmVuY2UuDQo+IA0KPiBJIHRoaW5r
IHRoYXQgd291bGQgYmUgbXVjaCBzaW1wbGVyIGZvciBldmVyeWJvZHkuDQo+IA0KPiBJIHN0aWxs
IHdhbnQgdG8gY29uZmlybSB0aGF0IHNwYWNlcyBhcmUgYWxsb3dlZCBpbiBuYW1lcy4gQ2FuIHlv
dSANCj4gY29uZmlybT8NCj4gDQo+ID4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4gPiBGcm9tOiBBbGV4ZXkgTWVsbmlrb3YgW21haWx0bzphYW1lbG5pa292QGZhc3RtYWlsLmZt
XQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyLCAyMDE3IDEyOjA2IEFNDQo+ID4gVG86
IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiA+IENjOiBkcmFmdC1pZXRmLW9hdXRoLWFtci12
YWx1ZXNAaWV0Zi5vcmc7IEhhbm5lcyBUc2Nob2ZlbmlnIA0KPiA+IDxIYW5uZXMuVHNjaG9mZW5p
Z0BnbXgubmV0Pjsgb2F1dGgtY2hhaXJzQGlldGYub3JnOyANCj4gPiBIYW5uZXMuVHNjaG9mZW5p
Z0BnbXgubmV0OyBvYXV0aEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IEFsZXhleSBNZWxuaWtvdidz
IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1vYXV0aC1hbXItdmFsdWVzLTA1Og0KPiA+ICh3aXRoIERJ
U0NVU1MgYW5kIENPTU1FTlQpDQo+ID4gDQo+ID4gQWxleGV5IE1lbG5pa292IGhhcyBlbnRlcmVk
IHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+IGRyYWZ0LWlldGYtb2F1dGgt
YW1yLXZhbHVlcy0wNTogRGlzY3Vzcw0KPiA+IA0KPiA+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNl
IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIA0KPiA+IGFsbCBlbWFp
bCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0
byANCj4gPiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gPiAN
Cj4gPiANCj4gPiBQbGVhc2UgcmVmZXIgdG8NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNn
L3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gPiBmb3IgbW9yZSBpbmZvcm1hdGlv
biBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiA+IA0KPiA+IA0K
PiA+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4g
YmUgZm91bmQgaGVyZToNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm
dC1pZXRmLW9hdXRoLWFtci12YWx1ZXMvDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCj4gPiAtLQ0KPiA+IERJU0NVU1M6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAtLQ0KPiA+IA0K
PiA+IFRoaXMgaXMgYSBmaW5lIGRvY3VtZW50IGFuZCBJIHN1cHBvcnQgaXRzIHB1YmxpY2F0aW9u
LiBIb3dldmVyIEkgDQo+ID4gaGF2ZSBhIHNtYWxsIHNldCBvZiBpc3N1ZXMgdGhhdCBJIHdvdWxk
IGxpa2UgdG8gZGlzY3VzcyBmaXJzdC4NCj4gPiANCj4gPiBBcmUgbm9uIEFTQ0lJIG5hbWVzIG5l
ZWRlZD8gKFRoaXMgaXMgYSBwcm90b2NvbCBlbGVtZW50LCBub3QgYSBodW1hbiANCj4gPiByZWFk
YWJsZSBzdHJpbmcsIHNvIG5vbiBBU0NJSSBpcyBub3QgbmVlZGVkKS4gQXJlIEFTQ0lJIHNwYWNl
cyANCj4gPiBhbGxvd2VkIGluIG5hbWVzPyBNb3JlIGdlbmVyYWxseTogd2hhdCBkbyB5b3UgY2Fs
bCBwcmludGFibGUgY2hhcmFjdGVyPw0KPiA+IA0KPiA+IA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4g
LS0NCj4gPiBDT01NRU5UOg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gLS0NCj4gPiANCj4gPiBJbiBT
ZWN0aW9uIDYuMTogc3VnZ2VzdGlvbiB0byBmaXJzdCBkZXNjcmliZSBJQU5BIHJlZ2lzdHJhdGlv
biANCj4gPiBwb2xpY3ksIHRoZW4gZGVzY3JpYmUgcmVzdHJpY3Rpb25zIG9uIHJlZ2lzdGVyZWQg
bmFtZXMuIE90aGVyd2lzZSANCj4gPiB0aGUgY3VycmVudCB0ZXh0IGRvZXNuJ3QgZmxvdyB3ZWxs
Lg0KPiA+IA0KPiA+IEkgYW0gYWxzbyBhZ3JlZWluZyB3aXRoIFN0ZXBoZW4ncyBESVNDVVNTLg0K
PiA+IA0KPiA+IA0K


From nobody Tue Feb 28 18:48:20 2017
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24AA129473 for ; Tue, 28 Feb 2017 18:48:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTKCKr0I7zq4 for ; Tue, 28 Feb 2017 18:48:18 -0800 (PST)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0ED129434 for ; Tue, 28 Feb 2017 18:48:17 -0800 (PST)
Received: by mail-qk0-x22c.google.com with SMTP id s186so49821701qkb.1 for ; Tue, 28 Feb 2017 18:48:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SprW0Nt3Eg4AfeZPCIQd3f9c7Xj2NSUr818TKyVRgfY=; b=LvyJqwDHtDuxkuru9ewlaMdwTHeFEzHqetkKNbcp0eCyKj1mhyXfd5wVPeLSOdoVWy dfN8CT0BkNsUw2p1LvLMp28F/mYnpw0K4M7PowQ0IVSXhCdIPL3dbwykNyJqm4wix36l sDw/O5oz5kcC0K6mH8nPC9ve2yxGAnD8zNMhDojNn8Wzk57eH/vPdrHlXlclNbLDw6VG kLWSm3ciGswfb/ej0R/49uf6sQQYnEsFVSDnUYZUYOmg28xtYtxBtB/SL7Ir6MUUk3O4 Am23AftVLCiX4zXWg8qy+klvRAAxPnFdTkxew3pjFAldq+QCAD+6v25+rHkB2R5mOixK XbEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SprW0Nt3Eg4AfeZPCIQd3f9c7Xj2NSUr818TKyVRgfY=; b=c5lRhG/Srq78Nvg7QF2ErgqbBB0jMtXPlIXVxqZXSKU0e1nDFcXn3SFY+0/P8Jili7 0nPZSNIxq1yhqDS8a+Yj4ZDxM2SCCrZ/8yF0aVIyrSk9FLJ3PYmq6U3LGVfgRZmsORus MMS84yoH5fyJt8oYqQAZy20BaocmaRMucK//aMZLQ4tM/wzaCZ5IB4dazRzqQBi983ml xJFwMObkLR9ra640mqcgmq0ZS0ifWZ3niGqajVrMXr4zkMDX9SJx8Da6kUzBXcLtCJEG 4WmNPMc2PtADnNYeSpCIooh7nUEjdvs7ZEKmxRdlSJPfQmNCUPkmD1Mf6kvlJRA6JN2a W3xA==
X-Gm-Message-State: AMke39kXJvASzzgZK+fBDhs3/IZbzbOelHS1V3ENSS8Eqfjw6TSt+0WI+CZ+uHViwBpxWdjDkpLbZ+dDMQAIFfSG
X-Received: by 10.55.144.4 with SMTP id s4mr6766149qkd.101.1488336496591; Tue, 28 Feb 2017 18:48:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.36.203 with HTTP; Tue, 28 Feb 2017 18:47:56 -0800 (PST)
In-Reply-To: 
References:   
From: William Denniss 
Date: Tue, 28 Feb 2017 18:47:56 -0800
Message-ID: 
To: "Manger, James" 
Content-Type: multipart/alternative; boundary=94eb2c057a702fe0c20549a258e3
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] FW: draft-ietf-oauth-device-flow: url with code
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Mar 2017 02:48:20 -0000

--94eb2c057a702fe0c20549a258e3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 28, 2017 at 6:06 PM, Manger, James  wrote:

> >>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04
>
> >> Transmitting a URI via Bluetooth, or NFC, or QR code, is quite common.
> In such cases it would be nicer to transmit the user_code as part of the
> URI.
>
> > I don't really see the benefit.
>
> If the device is always used with a pre-installed companion mobile app: n=
o
> benefit.
> If the device has ample screen size for "To register, visit  and
> enter ": no benefit.
> If the device can use NFC/BLE/QR-code/=E2=80=A6 to transmit a URI: benefi=
t; can
> get verification_uri and user_code to a mobile browser without anything
> else (on the device or on the mobile).
>
> Scenario: a device with no screen, just a few LEDs; the instructions say
> "to activate, tap the device with your mobile (after enabling NFC or
> bluetooth)".
> User taps with mobile; browser launches; AS shows picture of device and
> asks user to confirm LEDs are flashing red/green/red/green=E2=80=A6 (on f=
orm with
> CSRF-protection); user click Yes; next device polling token request
> succeeds.
>
> This scenario is harder without a standard way to combine verification_ur=
i
> and user_code into a single URI.
>

I don't see how this would be interoperable, how would the AS know about
the specifics of the device such as the color of the LEDs?  If you're
already relying on implementation specifics, like negotiating with the
client about the color of the LED, then you could also negotiate that the
code can be appended in any way that you both agree.  This is why I
suggested such advanced pairing would be out-of-scope.

I think a more plausible interop scenario would be that the URI and the
code are displayed as normal, but there's a step-up convenience option,
like QR code or NFC that combines the two. For users with a QR reader or
NFC they could use it, others could do it the old way.


> If you're doing some kind of out-of-band transmission (which is mentioned
> as out of scope of the spec) there's no reason you can't simply transmit
> both pieces of information.
>
> My guess is that "transmitting both pieces of info" requires
> special-purpose code that understands those 2 pieces. Whereas browsing to=
 a
> transmitted URI is generic.
>
> >  We've done that before, and this is what we do.  Having the data
> separate did not really alter the implementation of this, and combining i=
t
> wouldn't measurably make it simpler (but it would make the spec more
> complex).
> >
> > Also if the AS really wanted to, there's nothing to stop it including
> whatever parameters it wanted in the verification URI today (which could
> include the user code).
>
> > So I'd prefer to keep 1 protocol, designed for the browser model (which
> is the only thing in-scope in the spec), that can potentially work with a
> wide range of cases.
>
> It is still the browser model; it's just how the URI and code get to the
> browser.
>
>  >> Perhaps both modes could be supported by saying the user_code can be
> included as a query parameter on the verification_uri when it is more
> convenient for a device to transmit a single URI. Authorization Servers
> MUST accept this. The choice is to use user_code as the complete query
> string (eg https://example.com/device?wdjb-mjht) or specify a =E2=80=9Cco=
de=E2=80=9D
> parameter name (eg https://example.com/device?code=3Dwdjb-mjht).
>
> > -1. I know for sure Google's AS will not comply with that MUST. As it i=
s
> there are some phishing concerns around this flow (documented in the spec=
),
> and this change unfortunately makes the matter worse by allowing for
> single-click phishing.
>
> I didn't mean to imply the AS had to *finish* the flow immediately when
> uri?code was accessed. An AS can still display anti-phishing measures
> requiring explicit user clicks to continue. The AS could still display a
> picture of the device.
>
> I do concede that requiring a code to be manually entered is a specific
> phishing defence so any alternative should probably be specified separate=
ly
>

I know for sure that Google's AS will not implement this MUST. We've talked
about it in the past (including the unfinished pre-filled scenario you
outlined) and it was rejected due to increased phishing risk. I don't know
how others who've implemented early versions of this spec will act, but I
think introducing this MUST after so many years will harm interop.

I'm not necessarily saying that nobody should accept pre-filled codes
though, only that it was the direction my team went.

A MAY might be an option. E.g. the authorization server MAY accept the
authorization URI with an appended user code (appended in a standard way).
But that the client MUST still display the code in case the AS ignores the
param and requires it to be manually entered, and for verification purposes=
.

For servers who accept the pre-fill, I think the UX advice would be that
the user is still prompted to confirm the code visually.  Since the device
needs to display the code in all cases, even if only for confirmation
purposes, then that actually still works fine for an AS that decides to
require manual input.

That compromise could potentially work.


> > For example, we use the text today: "Enter the code displayed on your
> device". And we display a picture picture of the device to help guide the
> user as to the expected usage of this flow (this by itself isn't everythi=
ng
> =E2=80=93 but they are important hints).
>
>
> >> Recommending case-insensitive punctuation-ignoring alphabetic codes is
> good, but how does a user know this is the case for a particular code?
> Perhaps the advice needs to be to use a =E2=80=9Cfancy=E2=80=9D input fie=
ld with javascript
> to convert to uppercase as the user types and handle punctuation?
>
> > I believe that's covered:
> >
> >   The server should ignore =E2=80=A6
>
> I guess I read that as a suggestion for server-side code. But the user
> needs a hint at the client-side as they enter the code.
> This is a minor detail. A web form could, for instance, say "case and
> punctuation are ignored" below the code input field.
>

It wasn't meant to imply a server-side action, only that it's an
authorization server responsibility (which could be handled client side).
The text could be clarified if it's ambiguous.

William

--94eb2c057a702fe0c20549a258e3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, Feb 28, 2017 at 6:06 PM, Manger, James <James.H.Manger@t=
eam.telstra.com> wrote:
>>> https:/=
/tools.ietf.org/html/draft-ietf-oauth-device-flow-04



>> Transmitting a URI via Bluetooth, or NFC, or QR code, is quite com=
mon. In such cases it would be nicer to transmit the user_code as part of t=
he URI.



> I don't really see the benefit.



If the device is always used with a pre-installed companion mobile a=
pp: no benefit.

If the device has ample screen size for "To register, visit <uri>=
; and enter <code>": no benefit.

If the device can use NFC/BLE/QR-code/=E2=80=A6 to transmit a URI: benefit;=
 can get verification_uri and user_code to a mobile browser without anythin=
g else (on the device or on the mobile).



Scenario: a device with no screen, just a few LEDs; the instructions say &q=
uot;to activate, tap the device with your mobile (after enabling NFC or blu=
etooth)".

User taps with mobile; browser launches; AS shows picture of device and ask=
s user to confirm LEDs are flashing red/green/red/green=E2=80=A6 (on form w=
ith CSRF-protection); user click Yes; next device polling token request suc=
ceeds.



This scenario is harder without a standard way to combine verification_uri =
and user_code into a single URI.

I don&=
#39;t see how this would be interoperable, how would the AS know about the =
specifics of the device such as the color of the LEDs?=C2=A0 If you're =
already relying on implementation specifics, like negotiating with the clie=
nt about the color of the LED, then you could also negotiate that the code =
can be appended in any way that you both agree.=C2=A0 This is why I suggest=
ed such advanced pairing would be out-of-scope.

I =
think a more plausible interop scenario would be that the URI and the code =
are displayed as normal, but there's a step-up convenience option, like=
 QR code or NFC that combines the two. For users with a QR reader or NFC th=
ey could use it, others could do it the old way.

<=
br>

> If you're doing some kind of out-of-band transmission (which is me=
ntioned as out of scope of the spec) there's no reason you can't si=
mply transmit both pieces of information.



My guess is that "transmitting both pieces of info" requir=
es special-purpose code that understands those 2 pieces. Whereas browsing t=
o a transmitted URI is generic.



>=C2=A0 We've done that before, and this is what we do.=C2=A0 Having=
 the data separate did not really alter the implementation of this, and com=
bining it wouldn't measurably make it simpler (but it would make the sp=
ec more complex).

>

> Also if the AS really wanted to, there's nothing to stop it includ=
ing whatever parameters it wanted in the verification URI today (which coul=
d include the user code).



> So I'd prefer to keep 1 protocol, designed for the browser model (=
which is the only thing in-scope in the spec), that can potentially work wi=
th a wide range of cases.



It is still the browser model; it's just how the URI and code ge=
t to the browser.



=C2=A0>> Perhaps both modes could be supported by saying the user_cod=
e can be included as a query parameter on the verification_uri when it is m=
ore convenient for a device to transmit a single URI. Authorization Servers=
 MUST accept this. The choice is to use user_code as the complete query str=
ing (eg https://example.com/device?wdjb-mjht) or specif=
y a =E2=80=9Ccode=E2=80=9D parameter name (eg https://exa=
mple.com/device?code=3Dwdjb-mjht).



> -1. I know for sure Google's AS will not comply with that MUST. As=
 it is there are some phishing concerns around this flow (documented in the=
 spec), and this change unfortunately makes the matter worse by allowing fo=
r single-click phishing.



I didn't mean to imply the AS had to *finish* the flow immediate=
ly when uri?code was accessed. An AS can still display anti-phishing measur=
es requiring explicit user clicks to continue. The AS could still display a=
 picture of the device.



I do concede that requiring a code to be manually entered is a specific phi=
shing defence so any alternative should probably be specified separately
=C2=A0
I know for sure that Google's AS wi=
ll not implement this MUST. We've talked about it in the past (includin=
g the unfinished pre-filled scenario you outlined) and it was rejected due =
to increased phishing risk. I don't know how others who've implemen=
ted early versions of this spec will act, but I think introducing this MUST=
 after so many years will harm interop.

I'm no=
t necessarily saying that nobody should accept pre-filled codes though, onl=
y that it was the direction my team went.

A MAY mi=
ght be an option. E.g. the authorization server MAY accept the authorizatio=
n URI with an appended user code (appended in a standard way). But that the=
 client MUST still display the code in case the AS ignores the param and re=
quires it to be manually entered, and for verification purposes.
=

For servers who accept the pre-fill, I think the UX advice w=
ould be that the user is still prompted to confirm the code visually.=C2=A0=
 Since the device needs to display the code in all cases, even if only for =
confirmation purposes, then that actually still works fine for an AS that d=
ecides to require manual input.

That compromise co=
uld potentially work.
=C2=A0

> For example, we use the text today: "Enter the code displayed on =
your device". And we display a picture picture of the device to help g=
uide the user as to the expected usage of this flow (this by itself isn'=
;t everything =E2=80=93 but they are important hints).





>> Recommending case-insensitive punctuation-ignoring alphabetic code=
s is good, but how does a user know this is the case for a particular code?=
 Perhaps the advice needs to be to use a =E2=80=9Cfancy=E2=80=9D input fiel=
d with javascript to convert to uppercase as the user types and handle punc=
tuation?



> I believe that's covered:

>

>=C2=A0 =C2=A0The server should ignore =E2=80=A6



I guess I read that as a suggestion for server-side code. But the user need=
s a hint at the client-side as they enter the code.

This is a minor detail. A web form could, for instance, say "case and =
punctuation are ignored" below the code input field.
<=
div>
It wasn't meant to imply a server-side action, only =
that it's an authorization server responsibility (which could be handle=
d client side).=C2=A0 The text could be clarified if it's ambiguous.

William




--94eb2c057a702fe0c20549a258e3--