From nobody Mon Aug 1 13:00:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776FB12DB6C for ; Mon, 1 Aug 2016 13:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bfov_HTJPw9I for ; Mon, 1 Aug 2016 13:00:47 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3356E12D10B for ; Mon, 1 Aug 2016 13:00:47 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id m101so193096305ioi.2 for ; Mon, 01 Aug 2016 13:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=E91tcgxilFvOzN/ckGNJWEdSL8m6CacV79T2nvQ00Kw=; b=mKutfMGCxNPoVztqhfh7tmDBouB6go8/xlvasXQFl0F+raMdrKFTdJdQwPY70kGxyw FiQ6Ejr/IB4DP0jNp1aiVgO+oa7ZcMb2WCf9P6zuF7AMLhTc0PU3ikC8WxvMu3OlXY+V DM9CnyKY7lXR0UmEjl3q4ZrEe/eoVaYlmxLII= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=E91tcgxilFvOzN/ckGNJWEdSL8m6CacV79T2nvQ00Kw=; b=MZF7euioN/rzFCZlUoEEzOG5mycBDqFzAzOPBNQ4Sxff2y7HtNhA14IVq+rcfLYmtI AhRLCRoJuHtzeyzvfc+yw5ITcW+H+x1gHDIUg2ZLQOK5VM4xDIuzsJUyB2anyF9QSx0r pkIm7Nvr+9jgxSDg4gpLIPcHH2EQrOYmNiQRc0bvH92U7Coed3FsqxYDe6a7uq8TCmJC 9Ky+Z4OI/kNhVK7dKDb0/CzAmF4AWbELpS4ieMEFnjCc5QbXCakgQu8I0KoHyAExQJYw k39HcnJAuwx2q+wKiVCrdLx4j/ujtG+6+KeJlGEszk/pQ3nlnMcGHISp/xHOvFYQ5B/q 7/yQ== X-Gm-Message-State: AEkooutP2A6QqL9NYM7EAE7Itk9Q4Lnn+eK6EXZiBjiTcddVi5I//E0koP6xqEKfwzKc5wrcfasB9NzjXG8dTEZ+ X-Received: by 10.107.8.140 with SMTP id h12mr60161521ioi.95.1470081646073; Mon, 01 Aug 2016 13:00:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Mon, 1 Aug 2016 13:00:15 -0700 (PDT) From: Brian Campbell Date: Mon, 1 Aug 2016 14:00:15 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a113fb6b04e39990539080ef2 Archived-At: Subject: [OAUTH-WG] Following up on token exchange use case 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, 01 Aug 2016 20:00:48 -0000 --001a113fb6b04e39990539080ef2 Content-Type: text/plain; charset=UTF-8 During the meeting in Berlin Tony voiced concern about a use case he had for token exchange. Honestly, it's still not entirely clear to me what that use case is or what would need to change in support of it. I'd like to better understand the use case and see if it's something that can reasonably be accommodated with Token Exchange. During the meeting Tony referred back to an earlier email where he said, "want_composite is not really the effect we are looking for since it provides for a single token, the use case we have is where you want the ability to use the subject_token and the actor_token in combination and not as a composite of only the claims." The want_composite parameter came about during some iterative work on the document (between I-D publications) last year. At first the client could express that it wanted a composite token, one containing delegation semantics, with the inclusion of the actor_token parameter. One of the other editors suggested, however, that the actor_token token might be necessary for authorization in cases even when the client wasn't asking for a composite token and that placing the desire for delegation semantics on it was overloading the parameter too much. I introduced the want_composite parameter to give the client such a signal independent of the actor_token parameter. My (admittedly incomplete) understanding of WS-Trust is that the client/requester can make such an indication and I was trying to follow that model. However, I'm not sure it's needed or even makes much much sense. Ultimately it's the server's decision about how to construct the issued token and what to include in it. It is the server's policy, not a client signal, which makes the determination. So the want_composite parameter is really just noise that makes the spec longer. And, from the quote above, seems might also lead some readers to incorrect conclusions about what can and cannot be returned in a token exchange. I'd propose then that the want_composite parameter be dropped from the document. --001a113fb6b04e39990539080ef2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
During the meeting in Berlin Tony voiced concern abou= t a use case he had for token exchange. Honestly, it's still not entire= ly clear to me what that use case is or what would need to change in suppor= t of it. I'd like to better understand the use case and see if it's= something that can reasonably be accommodated with Token Exchange. During = the meeting Tony referred back to an earlier email where he said, "wan= t_composite is not really the effect we are looking for since it=20 provides for a single token, the use case we have is where you want the=20 ability to use the subject_token and the actor_token in combination and=20 not as a composite of only the claims."

The want_composite parameter came abo= ut during some iterative work on the document (between I-D publications) la= st year. At first the client could express that it wanted a composite token= , one containing delegation semantics, with the inclusion of the actor_toke= n parameter. One of the other editors suggested, however, that the actor_to= ken token might be necessary for authorization in cases even when the clien= t wasn't asking for a composite token and that placing the desire for d= elegation semantics on it was overloading the parameter too much. I introdu= ced the want_composite parameter to give the client such a signal independe= nt of the actor_token parameter. My (admittedly incomplete) understanding o= f WS-Trust is that the client/requester can make such an indication and I w= as trying to follow that model. However, I'm not sure it's needed o= r even makes much much sense. Ultimately it's the server's decision= about how to construct the issued token and what to include in it. It is t= he server's policy, not a client signal, which makes the determination.= So the want_composite parameter is really just noise that makes the spec l= onger. And, from the quote above, seems might also lead some readers to inc= orrect conclusions about what can and cannot be returned in a token exchang= e.

I'd propose then that the want_composite paramete= r be dropped from the document.=C2=A0
=C2=A0
--001a113fb6b04e39990539080ef2-- From nobody Wed Aug 3 00:45:58 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931D812D8B0 for ; Wed, 3 Aug 2016 00:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, 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 cWCGYrWcAPTr for ; Wed, 3 Aug 2016 00:45:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1015912D8F3 for ; Wed, 3 Aug 2016 00:45:53 -0700 (PDT) Received: from [192.168.10.132] ([88.117.91.175]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lqm3a-1b0UCj17EQ-00eOZO for ; Wed, 03 Aug 2016 09:45:51 +0200 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <33052033-0992-ceb8-4390-6837017b140e@gmx.net> Date: Wed, 3 Aug 2016 09:45:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gkvjROqqxTEA0UP3h56vKdEKLMRj6KUBt" X-Provags-ID: V03:K0:OYjamSW3LvjFsbc52sRHHS6HwOoDkV6ectKLT64IDIblBUwKKRU jb7eNfGL8nNQdski9WBhh3PxoUFpjE4CsyOw75sqhy/nrXHsQpIJTaBIbfGBmSbnUFsUBd7 kY7kjfWeITx6aS3/cRQ50fBDSm9bid4QmJRDD4yq2Xcfxn9M1LvaS9hPLGKqPFLNZjXudAi s0AtBWtUlebfC8ZKNeDug== X-UI-Out-Filterresults: notjunk:1;V01:K0:GBTBADzA/vg=:+QlSdSyYGGg56htLAKQQrE gjQTVrm0lbZNyzpf3aNE+Nv1kN6TuurV8Ubj9KjTtbDXMrOBz6mytE1kWyuJRSACOjsJG6KNi i0X1DxGynhGITMIIBihilALzv8YkSeHwOtL6I0l72VfPnErl0cSM1u7HYqrqx6nRjYjHgybmM mh5j9cGEh/tnY2PoJ43ePzbDHWIIeYLc9AaaQByrdtCN8HUh9E7iIB5RVId2yQe7Q/tf1A7BG tWkQ7jjoiQJapJX1xwfSuaarhld+1RGvEP95uoG0aaLRa+QI3WmaCuOQGic4F1QEh8OpXbOLf iOe+N/EeD5FFdfv0cx/DM3wdxWWAgLsN2tTkWVXbgPmBrxeikgCkkFG4PFxl7DWsGNxqdOfRe DfmhHr9geZgfH+Iko1RTFWE4LJCAJ9aUcOqjdH+XpDtep+cLaJYzB+G4p6lZ3Tgsw/xXUX6yb 1b/bEL06nmOZ0CPYXgSYYF273UAendI2CUaw93EpvviSMt6Pr/SIdueHArxKB19JnD0R2ObpO aXPFX4Ss4MMqO4plwSgK7meCgnOwF67TAG2EUzBEhfYuJv9kFVa1Ip/jQp29FF07m4FdPOhVb Xmte/XYNnk7WioZDXzzgf3q7cl7OX1iPoJ1+V8K6TVo/HR0mWZW0FSIFOswRSVeq2q2vBxXS5 5hGw9hBe4PRy3vPY8nHQ6Y6o6LSYdNBHlVBiQiNq1FpZpXPqHQUiABD1XU5b+x7Rzers31/P7 JTLtpEkDGRERCveDXnIKXozL/+s6XZL5S851IKGO+hM8EKu/saqP3EPoZQM= Archived-At: Subject: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0 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, 03 Aug 2016 07:45:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gkvjROqqxTEA0UP3h56vKdEKLMRj6KUBt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, this is the call for adoption of the 'OAuth 2.0 Token Binding' document bundle* following the positive call for adoption at the recent IETF meeting in Berlin. Here are the links to the documents presented at the last IETF meeting: https://tools.ietf.org/html/draft-jones-oauth-token-binding-00 https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 Please let us know by August 17th whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Ciao Hannes & Derek *: We will find out what the best document structure is later, i.e., whether the content should be included in one, two or multiple documents.= --gkvjROqqxTEA0UP3h56vKdEKLMRj6KUBt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXoaE3AAoJEGhJURNOOiAt4OAH/3+LY2gUmk+iweMAo9oBPGs9 TLytPPeIXP8HoNOIy798lXHCCPpLCgW8sXkLr/h3n4sbKv4+KRH+wWbJCP05KbHs kSCv6bM7qJCUt2QkUtN6YU0EKLe6xdHRu8EZ5EX0cw0Ao0ZQX0yYu1rUv+okT9pi j9InoiTfvW5PNpMTtBvs4PSw2jPUNOGgmqBFdIzXqhz1W5fMZBdsz7SR7+N4nt50 JClVkMwLBXLmLhtXjyOTfJXuXXnmdBqJc31p1g6e/gIaK+TD16KHxISJKktCY3ES ikS+dKWRanhh+ix4Sld9a834zl6lFx1nOfXMuHGvILJvlf5G5x6p7X3pYzmjxQI= =jmTz -----END PGP SIGNATURE----- --gkvjROqqxTEA0UP3h56vKdEKLMRj6KUBt-- From nobody Wed Aug 3 00:50:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ECE12D9AB for ; Wed, 3 Aug 2016 00:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, 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 5UZz7jiYPXBs for ; Wed, 3 Aug 2016 00:50:25 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2A012D8B0 for ; Wed, 3 Aug 2016 00:50:24 -0700 (PDT) Received: from [192.168.10.132] ([88.117.91.175]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LxPuE-1bBWcu3kks-016vnO for ; Wed, 03 Aug 2016 09:50:23 +0200 References: To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Forwarded-Message-Id: Message-ID: Date: Wed, 3 Aug 2016 09:50:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vaVDC4HipvNLelu034URrR4vrCOd0RkoV" X-Provags-ID: V03:K0:8NBhqEPtrssyN/d+Ym7HOh1OZ54DFpcEOgGR/CsZGQ8yjEB9fcL Nuhb4PU7BhEzekPrVXW0Ec40YmJA2eKm8z0f70DmamTQ/JPL0fwzQPtO5uld1m5CCHMh2GN EyDMkZc/1CErLdteDMgRm6GWyvCwtleQbzLKQw+7GmW7Qrn8UFC1nUrqZEPbRLqYGrD3Iwk 59rvwEBvIKd5GqhitXTrA== X-UI-Out-Filterresults: notjunk:1;V01:K0:RdDWYq/Q1wo=:Djnr17CkqMreaEcfbHrFYW 5Brk7fujoefmhUC9gX2CW965a9yey8yITIv5QahplZP0KD3sf0+SSYYZf40HeCTFznmEb4n7u /pe0Qi5SahpwHryl04/A5T5Arg/9tTSwtrxhUhigNNW8hvAPg9O/+cr+2NGAwc9iFyRsoU+F8 VOmlf7Lxr1PeWTnG77o2ITqdBStN6kmNVHIPJPMti/XaBXKsxrFiY57zn62AaHUxTldYrsjiA 8Fd0f85kNe+kIHsJb+vuTPsStlKsZFA4mUPfEY0Bmpk3aAYpx0UXUC4znnTcZvN7UawkcoZ7p i6gUl7R1zCKFVcJp+/it65GyoDfAwq9hMz8+PSnhgEz0XjSB9PWDhLXsthPCWjX4v7BXw0zmT 4umhdZXB5Su1WlsljqSOob3pcr8pqF866v3Xp7bVzA8JHgp4k3PThF29bucJ9ZtN4SLwIBu01 AiSLmOp9Z5GKrPjL75v0XLiB0WEo50N7RjYCFV87FsAdieGvEFM/IWLiOMqt1g9htkz0BeoNV GeUrH2DZc2cqFmmYxjljE8tujUI4ISq7eEkkmtO9VkoqkVMNzWRG7EphTpHtu4zwjY0l0ulVs vot1AvpxAzqCXPzp92TYp7qiPjfxwse//Gg8efUiZkwJeYaMKxp2isLM90992k5xYzdevOGya hcctjtjGJQ3xcIy1DnZ/A0xqSuKfc4QOHZYYijh9T20rmzpAKha7DloecRhHJPJBgoHEKQi/1 7pGP/gSY2wpgahCscCoMDzFEBmqp7PfuC2s46GDwxeX44Jd2vk+QTUkK67k= Archived-At: Subject: [OAUTH-WG] Review of draft-ietf-oauth-amr-values-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: Wed, 03 Aug 2016 07:50:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vaVDC4HipvNLelu034URrR4vrCOd0RkoV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mike, Phil, Tony, I have read through draft-ietf-oauth-amr-values-01. My earlier comments have been addressed. As a shepherd I nevertheless have a few questions/remarks: 1) The term 'multiple-channel authentication' is unfamiliar to me. Could you give me an example or a reference to a specification? 2) PIN: The use of RFC 2119 language appears to be inappropriate. 3) Could you explain me what 'risk-based authentication' is? While you provided a reference 4) Could we generalize the term 'wia' to operating systems other than Windows as well? 5) I am not sure whether all normative references indeed need to be declared as such. For example, 'otp' is defined in a very generic fashion but you list HTOP, and TOTP as normative references. I would rather see HTOP and TOTP as a standardized examples of one-time-passwords. IMHO the story would be different if you indeed want to differentiate between the different technical mechanisms itself. This is a reasonable approach as well if the security differences between the mechanisms is important for the given application. Ciao Hannes --vaVDC4HipvNLelu034URrR4vrCOd0RkoV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJXoaJIAAoJEGhJURNOOiAt5E4H/1BRZ87D9r6Aels8yXG/pbJL iWR6gG0F7CvUFkURfY5hMUJ5f8B9JFlak065gNUb/4WMmzK96UF8LtY6yn+D3Y58 rKJ0IVeFmwrOA9X4suo/HRkfMAC5JrgKgFZRoBcYbsbgdL8JGxsnch2l2u0qkXEp JyvAvHlQ40QxA+7xNfLNC0EbdE8miPC3iKABIxmBeiNUoJ16VeLueC8I0/lZAOfr rQzwFbj0Pr2GUYP88sBoAsMBpT9mVlcutl501cJuREPiz2VabO0MkMgB/Syguq30 y7qu31GveOXDoo/uz2C6nKB/eT4Ec4QN7r0I+KYYC3an8oVEukdBHdCSVLkLSpc= =QTOO -----END PGP SIGNATURE----- --vaVDC4HipvNLelu034URrR4vrCOd0RkoV-- From nobody Wed Aug 3 03:08:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B795112D0BA for ; Wed, 3 Aug 2016 03:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 dgw5ntz3B_ZE for ; Wed, 3 Aug 2016 03:08:31 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 8E22712B014 for ; Wed, 3 Aug 2016 03:08:31 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id o80so328427111wme.1 for ; Wed, 03 Aug 2016 03:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=yQ5ZvCU3u7h14ggMJYRZt+gTHQx2Ea5tHpWvgJCc4GQ=; b=wVdfAAN3LYkcYJfnHgSwMjcVzv+Ghx/f2QU6V9imvZNV+viSRKz9RDQ70AGwL2loOg g2QlRaYVp9uV1LmAlO7TYs3BHVSSNYCfdLx7gerWpjhqHaBVs+LiXas+XeEzTWPTYdKk S4pHPAc9+9xNbH3iyfz/JCPx8qpFBoN7VNQ9bYUxUHeS3p3tD3HIdDFChSn7beBIQl5s 6BkCJ6sIJdYySzZQGeG/0Q5HKtJm2RhEia92lyPF8fe49zrRR0SMvXm/LTJ2sbtHttlz wlsmj3+5uwHyVeQ+vNcp3B/BcymNBKORsrK//rBTP7MhhrpJiNKqFDsduBbTGU9wuF+9 tZCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=yQ5ZvCU3u7h14ggMJYRZt+gTHQx2Ea5tHpWvgJCc4GQ=; b=Cy3B4OU4XsGjtb5+RAgVpd/ENMwOzkcRv7mBHcgnfffrrcehkyA+i81KxHj/KriUGT Ei3GQPMHc/fpJBinDO4wmMFzmhpSfZpAeKK4bLYJXIhSuYOotyNW3kZvSGJ8BPz18xng XGHEGFuo/PdW/2xXA2dgM+KTKkhsTTn+8q4latgvBsiOfz2rjbzuLtYxFC854mDU6tSZ n8N1mC6rW7H3qdYnJt1OEXjaK+3nK2gEIdnHmpvKXInZKvemPBbeHqfiHpwa/D39d3Zu 3VbVYGg2IjeigUxY+J7hiZhVD3ORY4hZ6QaUgHNQ4f3HcTb9GJ++W3jSuiPI3sy7jvWL UfTQ== X-Gm-Message-State: AEkooutJwth2C3W97IsLOQiipkjXaxOmWxWgKViQiqG55Izib5OXZzkN+Eeg62FrXtxBNA== X-Received: by 10.28.64.86 with SMTP id n83mr69886196wma.52.1470218909845; Wed, 03 Aug 2016 03:08:29 -0700 (PDT) Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id w129sm7317581wmd.9.2016.08.03.03.08.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Aug 2016 03:08:28 -0700 (PDT) To: "oauth@ietf.org" References: <5795F109.9040403@gmx.net> From: Sergey Beryozkin Message-ID: Date: Wed, 3 Aug 2016 11:08:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] Using IdToken instead of Access token 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, 03 Aug 2016 10:08:35 -0000 Hi All I hope this question is better suited for this list. Will have no problems redirecting it to the openid-connect list instead. Consider a user working with the client web application (OIDC RP) which authenticates the user with the OIDC authorization code flow at the end of which the client gets AccessToken + IdToken. Next the user requests something from the client which needs to access the RS to complete this request. And the idea is to have the client pass IdToken to RS and use various user claims inside this IdToken to enforce the access control at the RS level. My position it is likely wrong but I guess I may be missing something that will be either in favor or against it. The reason I think it is wrong is that if the client is using a code flow then the right approach for staying within the OAuth2 'world' is to use the access token to talk to RS and use IdToken only for the purpose of interacting with the user. The access token represents a proper user authorization and can have the extra scopes in addition to "oidc" which RS can depend upon in its access control restrictions. Next I'm arguing that if the IdToken is used instead then it is the case of the client impersonating the user. And refer to the STS for the REST of Us draft (I have a separate series of question on that draft). I'm saying the impersonation can work but ignoring the access tokens completely will make the overall solution much less flexible. I'd like to ask for some advice/guidance: - Is it a good idea at all for the client to use IdToken instead of AccessToken as explored above ? I suppose it can work, in the code flow the client gets the access token which, by default, only allows to access UserInfo. Perhaps the client impersonating IdToken for the purpose of accessing RS is not too bad after all. - Assuming the impersonation is OK, what is the right criteria for the client to choose to work with IdToken instead of the access token when accessing the immediate RS. It seems like if the impersonation is OK for the client to do then why have access tokens at all... - Assuming the impersonation is OK, does STS For the REST of Us shows the right and the only way it needs to be done ? I can imagine how it will work for the web app clients, but what about Implicit Clients. Many thanks, Sergey From nobody Wed Aug 3 08:56:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713D712D50D for ; Wed, 3 Aug 2016 08:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJb_XBo78Du2 for ; Wed, 3 Aug 2016 08:56:16 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC05212D77B for ; Wed, 3 Aug 2016 08:53:35 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id 38so247152013iol.0 for ; Wed, 03 Aug 2016 08:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UVTQcXCsj9uXuriCXElQk1c6grTSbnxm+Mt7+x7xWZo=; b=RlMcufTn33NfYsQP0pc7AHCpfnsMP1G6S06xBoIOtc4VzgUhwL/Xbvy5od+6DhJa93 SrXzOinbYlG4WaZTs/XrLCKVjkysMRPCP1jWdpNUS/NNjLJu2Z55/N6cjZslNWNNJWOA 2tISbbnk77MR7STXtYwSh2P/ahFqtjxKfJVYYuXkNfioDdSlKpRW/fTLhYxjwFyvoTxz QMof/7IU8NQwIBYnBndrI/XP1IpY04VKdKjZAWrJe8p92+21rjo1COxwx4VEOk+4CEEu fLGgZeP5U04DGufdpA3ScgJfrTWwM0+W3fWKoYCOs8ZakiKZwhNNAWsnMz1LAPOIINzl zIOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UVTQcXCsj9uXuriCXElQk1c6grTSbnxm+Mt7+x7xWZo=; b=hE21TtWtZ0lh8KQ4ecIqMJLmC6bsJ8uCMET0u/jaIZLu4wiW2trgJmqrofTlAZGAfQ qG6K4MFiN2ltKMQBY/ufouHjYUYdSYvzWONwtLXSsiBnZ3ZnEKBbbqaHP3fS8xEuWP0c tgp69NdL82JH7BCU9JXqwpFIgmg0RfFslCX85gwoSTYPGf35UZ5m/Lu/RvXecqi71tP8 gg6zdxslgZFbLqOijocQNdIX9XvUIinsjgbJwW/59BLrZc/A5EO96i0mtTaWY4U5Yryn 5I3QZXyNEdJRoSdfA5yuc58F2AuL02SdzuBzcntKgTm8UoAFgv6xap6+papcNizcIfSj BWZQ== X-Gm-Message-State: AEkoouvUGOvtdlTKAYmbt34gt+C9bt78Fn60yekang04eAw3xuAnTtP7N2oGAqI3pem+o0bx92MPqMz419w1Hg== X-Received: by 10.107.3.221 with SMTP id e90mr70653937ioi.17.1470239615274; Wed, 03 Aug 2016 08:53:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.42.3 with HTTP; Wed, 3 Aug 2016 08:53:14 -0700 (PDT) In-Reply-To: <57908256.7090107@gmx.net> References: <57908256.7090107@gmx.net> From: Dick Hardt Date: Wed, 3 Aug 2016 08:53:14 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113df87e01092205392cd6eb Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Working Group Last Call on "OAuth 2.0 for Native Apps" 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, 03 Aug 2016 15:56:20 -0000 --001a113df87e01092205392cd6eb Content-Type: text/plain; charset=UTF-8 I reviewed the document and have no comments. +1 to adoption On Thu, Jul 21, 2016 at 1:05 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > William has submitted an update, as promised during the OAuth WG session > on Monday. Hence, we will start a Last Call for comments on the "OAuth > 2.0 for Native Apps" specification. > > The document can be found here: > https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03 > > Please have your comments in no later than August 8th. > > Ciao > Hannes & Derek > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Subscribe to the HARDTWARE mail list to learn about projects I am working on! --001a113df87e01092205392cd6eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I reviewed the document and have no comments.

+1 to adoption

On Thu, Jul 21, 2016 at 1:05 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

William has submitted an update, as promised during the OAuth WG session on Monday. Hence, we will start a Last Call for comments on the "OAuth=
2.0 for Native Apps"=C2=A0 specification.

The document can be found here:
https://tools.ietf.org/html/draft-ietf-oa= uth-native-apps-03

Please have your comments in no later than August 8th.

Ciao
Hannes & Derek



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




--
=
Subscribe to the HARDTWARE mail list to learn abou= t projects I am working on!
--001a113df87e01092205392cd6eb-- From nobody Wed Aug 3 13:48:12 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0DC12B005 for ; Wed, 3 Aug 2016 13:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQwUvJsyBHL4 for ; Wed, 3 Aug 2016 13:48:09 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6B912D740 for ; Wed, 3 Aug 2016 13:48:09 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id p186so88950488qkd.1 for ; Wed, 03 Aug 2016 13:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aOG4qjglLqImxjgsVpc3A3DyePyD/99fSANGybZ2oa0=; b=bwhr0ImOX5VlBzCJ8yAdg1xsv3rsXKaeBn1SMt1KWBZf4rbOqK3xrYPeHHYDZV5qjO bGU7qbCkgHo/2BhLS97MDgjK6gxDPORBxHMSAL4SwkWrLA/3GD2i90aK9qRpb1UEXdtr 4GMUN7pQwBtINS59nrz3bpMaHmp8MkkVO7J09PsY5zb41opcubk3Bnz9bQvTA5yHBGav wa2sLkFSOajXO4Z5vGzydZSO8XR0KMZ/ocv1qGarhCN4WCSojZg0OFKIUEQkb665MGQX QzDgDsGl3C4Y+41PoCL7KkGszeLR8EHR5hYjKTDvs3qiYsCJjcgY1wnf7of5iPOx1Dwv VcSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aOG4qjglLqImxjgsVpc3A3DyePyD/99fSANGybZ2oa0=; b=fZf3nMTz1VY9iPTiwTL/exvt7W1MjR+hy9MPQGHl1+5KaXvEIFHrCIYu8SWVNDMc5D 9GjLvY45RqK4AKQk4/DPvYvQgnN5My+vTXZZLYsLjQAiwXvu3yLxPw3J723+PVQaBGWS zqYFkWKY0KEll0Wpxpnpxb30AfUNLI1tHQ9E21VSyyZu+GkmnuZPn2x3qKoy7djSSpk4 1acJYG+8WkRSnXOZK/6qu5h27DE/Chf6M+/benrZarjZKyiVKDij1Iyb1uA/KaOUMN5u 4j6gFr2C3ipmvtRtY95j9xYggmR85kJZBowNfW0rNfZ3mWHuQKxvMSSFIbWxCoSl+GK1 0pJg== X-Gm-Message-State: AEkoouu0JBJmanTzPgTwygfaB6admpS5uunv5w1izv4meTjx2HENEiB1vJYV9RFLutVWUxoY X-Received: by 10.55.109.196 with SMTP id i187mr2352599qkc.116.1470257288193; Wed, 03 Aug 2016 13:48:08 -0700 (PDT) Received: from [192.168.8.100] ([181.201.246.7]) by smtp.gmail.com with ESMTPSA id k8sm5089564qke.39.2016.08.03.13.48.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 Aug 2016 13:48:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <33052033-0992-ceb8-4390-6837017b140e@gmx.net> Date: Wed, 3 Aug 2016 16:48:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0 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, 03 Aug 2016 20:48:11 -0000 I accept these documents as a starting point of the Token binding work = in OAuth. John B. > On Aug 3, 2016, at 3:45 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > this is the call for adoption of the 'OAuth 2.0 Token Binding' = document > bundle* following the positive call for adoption at the recent IETF > meeting in Berlin. >=20 > Here are the links to the documents presented at the last IETF = meeting: > https://tools.ietf.org/html/draft-jones-oauth-token-binding-00 > https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 >=20 > Please let us know by August 17th 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 > *: We will find out what the best document structure is later, i.e., > whether the content should be included in one, two or multiple = documents. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Aug 3 13:49:54 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C10612D661; Wed, 3 Aug 2016 13:49:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160803204950.9683.46415.idtracker@ietfa.amsl.com> Date: Wed, 03 Aug 2016 13:49:50 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-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: Wed, 03 Aug 2016 20:49:50 -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 Authorization Server Metadata Authors : Michael B. Jones Nat Sakimura John Bradley Filename : draft-ietf-oauth-discovery-04.txt Pages : 23 Date : 2016-08-03 Abstract: This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-discovery-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-discovery-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 Wed Aug 3 13:57:10 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585FE12D520 for ; Wed, 3 Aug 2016 13:57:08 -0700 (PDT) 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, 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] 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 QiyBnygOw3Bz for ; Wed, 3 Aug 2016 13:57:05 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0135.outbound.protection.outlook.com [104.47.40.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED78912D5AE for ; Wed, 3 Aug 2016 13:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Mp+AqBv1RdlKNXmdCAH7YnWX3wefNUbduAhi8Zyg/iE=; b=OnQpd4ATeroGS07S0aVPKwIsQKD2OuU5Slroh3I4EqMWKF2+8enSANFLVbDWJhSM3XKOxXGdKM0QFBRxw45LCDcNhnqHiAjz6dSkhginizOzs9eQZ8+dUgUa6EazW82ERaOEttkG1LEic+shgE/gKRAEv3EOacwJvU1qKo3zgIY= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1648.namprd03.prod.outlook.com (10.162.130.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 3 Aug 2016 20:57:02 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0549.022; Wed, 3 Aug 2016 20:57:02 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Metadata Specifications Enhanced Thread-Index: AdHtxoyR4dM0hHOyS5GH0gznKhXjdQ== Date: Wed, 3 Aug 2016 20:57:02 +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.133.182.68] x-ms-office365-filtering-correlation-id: f8a9fcb5-55fa-4581-163b-08d3bbe0b833 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1648; 6:nUil5rgRp3gQDZMCvtFQ4IWWKfD5EcbUyWqrTE7rfJUQMFv4srrnXpcv5TJbEiKciIiV08MOY9RVKT2k58J+AsArdwIYhtO0AAPRCY78PdTzyl+f3FaTWZNKyimOcOlu2gjmHZn+7nKkXWtJZ37HRrHK1g0oJ3SDhUP4cSENIHsSXyTr2bvDail9hzoxyNBmlr2dEXP3r00A2srhAl9Ohl2r4MlmJtLDzLD2SMnjs6BD35wTQqPiIWGNFIgTxwORhXcyWDRIf2Us2Ww6bguhu4y2x7jppuWouNWeEUqk+51/T4Q58NorGiNQIjlFqsxfieH9GIDEAn/NKEKarzoVqw==; 5:yEX6cmiVbl6045czSj8EFnKotj/dyPxGyOsGCRS3cG8bxU3qW/7CXJujX+xjx08CIJVx6M5WF9Ukv0G6k9R9hcW0jlJexYLcRBXCRwOCKSdMXycfJ1VFQj9sRRQbtbdV5yual4zSRiXeiL6ZwesJOA==; 24:mX5T6USt3lAKLtfuyHJqZaU4CRwRhE4sZVzbn+SZpuNRbU9gRpTG99npEVPWmw9uYaqO2fTF/tW67VkMwukQLLmEyEUeItKQJrTsuzHbufg=; 7:izVpYW59DHylLVLEMSmdKNFZqwHlj8l9DjHvP9umYmZLVnV/3OjIw9ieSjIR884TRHPjD0n3JHqeQEy+qC0EZ3tFsct+2hqV4Nlo25ugVW6amZuZGJTMCLIHSYA9C2DL7V21l8apXyrAj/Lm5uMbnZQ1ehNK5opyNh3WWt1vVRQ2HJKUVcON+X5qdwbx98eiD6fqrVGhhUyqmlfhrUhHRjAZwuXUhFF7hssAsAAhJqa0fR64dxzAsxqkyxWJcLHt x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1648; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1648; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1648; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(189002)(199003)(105586002)(790700001)(189998001)(8990500004)(77096005)(3846002)(76576001)(102836003)(3480700004)(122556002)(2351001)(19617315012)(7736002)(6116002)(3660700001)(81166006)(74316002)(1730700003)(5005710100001)(10400500002)(15975445007)(229853001)(7846002)(8676002)(2900100001)(97736004)(110136002)(99286002)(81156014)(68736007)(8936002)(586003)(7906003)(86612001)(9686002)(107886002)(54356999)(50986999)(5002640100001)(5630700001)(450100001)(19300405004)(10290500002)(86362001)(19580395003)(92566002)(11100500001)(10090500001)(2501003)(19625215002)(101416001)(7696003)(106356001)(2906002)(16236675004)(66066001)(3280700002)(5640700001)(87936001)(33656002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1648; H:SN1PR0301MB1645.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: multipart/alternative; boundary="_000_SN1PR0301MB164525922A67410D2D87C9E8F5060SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2016 20:57:02.4794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1648 Archived-At: Subject: [OAUTH-WG] OAuth Metadata Specifications Enhanced 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, 03 Aug 2016 20:57:08 -0000 --_000_SN1PR0301MB164525922A67410D2D87C9E8F5060SN1PR0301MB1645_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The existing OAuth 2.0 Authorization Server Metadata specification has now been joined by a re= lated OAuth 2.0 Protected Resource Metadata specification. This means that JSON meta= data formats are now defined for all the OAuth 2.0 parties: clients, author= ization servers, and protected resources. The most significant addition to the OAuth 2.0 Authorization Server Metadat= a specification is enabling signed metadata, represented as claims in a JSO= N Web Token (JWT). This is analogous to the role that the Software Stateme= nt plays in OAuth Dynamic Client Registration. Signed metadata can also be= used for protected resource metadata. For use cases in which the set of protected resources used with an authoriz= ation server are enumerable, the authorization server metadata specificatio= n now defines the "protected_resources" metadata value to list them. Likew= ise, the protected resource metadata specification defines an "authorizatio= n_servers" metadata value to list the authorization servers that can be use= d with a protected resource, for use cases in which those are enumerable. The specifications are available at: * http://tools.ietf.org/html/draft-ietf-oauth-discovery-04 * http://tools.ietf.org/html/draft-jones-oauth-resource-metadata-00 HTML-formatted versions are also available at: * http://self-issued.info/docs/draft-ietf-oauth-discovery-04.html * http://self-issued.info/docs/draft-jones-oauth-resource-metadata-00= .html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1591 and = as @selfissued. --_000_SN1PR0301MB164525922A67410D2D87C9E8F5060SN1PR0301MB1645_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The existing OAuth 2.0 Authorization Server Metadata specification has now been join= ed by a related OAuth 2.0 Protected Resource Metadata specification.  This means = that JSON metadata formats are now defined for all the OAuth 2.0 parties: c= lients, authorization servers, and protected resources.

 

The most significant addition to the OAuth 2.0 Autho= rization Server Metadata specification is enabling signed metadata, represe= nted as claims in a JSON Web Token (JWT).  This is analogous to the ro= le that the Software Statement plays in OAuth Dynamic Client Registration.  Signed metadata can also be used = for protected resource metadata.

 

For use cases in which the set of protected resource= s used with an authorization server are enumerable, the authorization serve= r metadata specification now defines the “protected_resources” metadata value to list them.  Likewise, the protected resource metada= ta specification defines an “authorization_servers” metadata value to list the = authorization servers that can be used with a protected resource, for use cases in which those are enumerable.

 

The specifications are available at:

·       http://tools.ietf.org/html/draft-ietf-oauth-discov= ery-04

·       http://tools.ietf.org/html/draft-jones-oa= uth-resource-metadata-00

 

HTML-formatted versions are also available at:<= /o:p>

·       http://self-issued.info/docs/draft-ietf-oau= th-discovery-04.html

·       http://self-issued.info/docs/draft= -jones-oauth-resource-metadata-00.html

 

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

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1591 and as @selfissued.

--_000_SN1PR0301MB164525922A67410D2D87C9E8F5060SN1PR0301MB1645_-- From nobody Wed Aug 3 14:11:25 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4436812D87D for ; Wed, 3 Aug 2016 14:11:24 -0700 (PDT) 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 IBuOYSPmSLvU for ; Wed, 3 Aug 2016 14:11:21 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0091.outbound.protection.outlook.com [104.47.41.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75C2812B010 for ; Wed, 3 Aug 2016 14:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Cp9UzscNCgTfforrUo9v+VmwGXHtl3mJkverYdKTwkg=; b=XbAqLqehXn8YdQptebQKPi4ESbzn6ta//McQ+GU0JYNgRBYVRpnhUdNPjyxAB79ypxTwW3ELNlGSlhdIuAqTrzFqSnwcZ8uhZIT5xArcaKs0P2fbhWsRbfu03zJrX1ahd/UaMSEMsps/RcAQYqhGl/Nd4jVzbnM9UlfelpAJDbU= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 3 Aug 2016 21:11:18 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0549.022; Wed, 3 Aug 2016 21:11:18 +0000 From: Mike Jones To: John Bradley , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0 Thread-Index: AQHR7VsWxozis/7gSkyycDdfszr6OKA3tfMAgAAGVMA= Date: Wed, 3 Aug 2016 21:11:18 +0000 Message-ID: References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net> 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.133.182.68] x-ms-office365-filtering-correlation-id: b35c68b0-0364-43c4-c0f4-08d3bbe2b696 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1645; 6:L9xUPVHeZcuqz5E4IiRCu8V8mlukstZgS58JdoI+ZXJQzCeroaKzbptGDR4vhWQptiZeSB4bms4pIfjtidjrNkIkVHZdFItEA2wYEXDPNr93c3e2On7DroNphxfOFu+9XR+X+uj4KkUXEruTxGaiX3fnkc1T2BhW2J5r03c/o85s63QYI3qQ9KV3pSl36dDJcs4Ww8jGshKLhKvmaWS74UJ/+Xy8yNMaVSI8BxSDRyWBR7MKSFtjJqa/ZIkxydIMbXuTlDUZBNFJJhHJUFwg9RC5FPYjwsicjoHhdP/mDqvbdqsM/XiSZRj057XTD1QzkVa1tXZg5Rm8R7mueyRPSA==; 5:tGIWAxBfgwxp/rG/+ZafS+Kvzz8D69RwExvqg2UnFo8dmkpbSr/0e0098GSuqO9p+LYMMfSHsNQoldkh3oH4wJby42Vii5qAcGsYpr3+hpUJt1FFAaduf8HZWY2+F9NRIhASWNmE2EkBikYYRXIEbA==; 24:ASw3Q+TR7N4e+kypJB8it1NN8vB+P5tWnvgsmeAEOxyTXrYbs56RifXD1bQNadv6sD8RCt8fFwkGk34Fc91HJeWgQwrwN51sF86FuAkzgoI=; 7:MGbsJwnkiKBe4W6PoxopC6J3xhl5Ol9ySK7QxG4mn/tZGk1UIEa2j36O0qpssaJCxW0y8nbndBb1vQMlH/XIfubnj6vhUw9Oy20Dqu4cDUYPcT34ekJOR3uUZPKypLEKU2gGsn/IsDtoEZmBv9vwa8cRmlihqbrneWkQrNyt5AZT408B9UPb0TiZOoi47WtR5QCemweraOZVw4rymx6E0LoZI6yuMFKV38mHBWpD2/FHuBXew4RIgoP2tvRqmxsq x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1645; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(248736688235697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1645; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1645; x-forefront-prvs: 00235A1EEF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(377454003)(24454002)(53754006)(13464003)(3660700001)(50986999)(8676002)(15975445007)(76176999)(9686002)(87936001)(77096005)(2900100001)(81166006)(92566002)(66066001)(68736007)(11100500001)(105586002)(2950100001)(99286002)(33656002)(10090500001)(5005710100001)(86362001)(3280700002)(8990500004)(2906002)(106356001)(81156014)(8936002)(86612001)(122556002)(101416001)(19580405001)(10400500002)(10290500002)(4326007)(305945005)(3846002)(97736004)(586003)(76576001)(19580395003)(7696003)(6116002)(5002640100001)(5001770100001)(106116001)(102836003)(189998001)(54356999)(7736002)(7846002)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1645; H:SN1PR0301MB1645.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2016 21:11:18.8707 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1645 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0 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, 03 Aug 2016 21:11:24 -0000 I agree with the adoption of these documents as the starting point for OAut= h Token Binding work. -- Mike -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Wednesday, August 3, 2016 1:48 PM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0 I accept these documents as a starting point of the Token binding work in O= Auth. John B. > On Aug 3, 2016, at 3:45 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > this is the call for adoption of the 'OAuth 2.0 Token Binding'=20 > document > bundle* following the positive call for adoption at the recent IETF=20 > meeting in Berlin. >=20 > Here are the links to the documents presented at the last IETF meeting: > https://tools.ietf.org/html/draft-jones-oauth-token-binding-00 > https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 >=20 > Please let us know by August 17th whether you accept / object to the=20 > adoption of this document as a starting point for work in the OAuth=20 > working group. >=20 > Ciao > Hannes & Derek >=20 > *: We will find out what the best document structure is later, i.e.,=20 > whether the content should be included in one, two or multiple documents. >=20 > _______________________________________________ > 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 Aug 3 15:22:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A8312D8C5 for ; Wed, 3 Aug 2016 15:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiIq7OHMTQY0 for ; Wed, 3 Aug 2016 15:22:36 -0700 (PDT) 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 A8C0112D8C3 for ; Wed, 3 Aug 2016 15:22:36 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id x25so151438723qtx.2 for ; Wed, 03 Aug 2016 15:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r9mNDLndRl/zXgSZOsscYnZoF7DoMoww+9sNZwhnhi4=; b=ntj3RCZ+ggYwfEPOME/0OMFXoO55deonA5QVa/mFHqERWbhSKm3S0CR2LnkYWf4FOX OUOrlTkgPDVS9xVqv74Zdklpr0NF/+C15U2ymTLkRot5ZDMYqZcRJMK+WXtBySWqGheL i5AjfH7EyXfCyoYWZRAk33I8gcKkFsqnhxgF6IoqyQHhdkQ55kK7KWNupOpNt26rDGUb OLfGB+Fl/eP6B1+m/Y7VsNZ6S1Q1zSeeI0XlcSSkb78MppHbFtaOHnrUbDAkQ4j37pET fJwpe2iNmq8Bi42WUUo9/BLJgbtZ/F2XowP655Kw7ebexc3qizwIBvhOlHVUukP8r04e m4pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r9mNDLndRl/zXgSZOsscYnZoF7DoMoww+9sNZwhnhi4=; b=W7etqH997nWYsbD+F3pERNcrvWDxmeKUELZbedldkjMhaDOqEHEIvO0gdac7QtcycG H45nwrHQ9NINDmxx5Xy/moTOev5TN6IIcyOF+h9e6Z5J4TKfyIZfGjdmtw6u6i14II/e i9noRo/ctn4WIenBvB6EsWny2meZK0jJ8a9ZZDxtIdJYdfW3JqxfGu5ZKbb5qMi6pKL9 ApMVRx8GPbzG9aIMEzgToUTrQLPALh0Bxg9Q23F8k9xM9qz35KQn0yTfH8T8X4gUCx/x OhM6KpfuIlOtHTG5uy9fsfgcHlWmBFomoYVJA9IUXrjTtVT6dFa70l4TpZQo8Vx3xuNF a7Bg== X-Gm-Message-State: AEkoouvCBz1gNgxObyowOtDAcYR6Ikw8/V9SgRb3wWgxAJSijCKYEgYP6iJCkh7CRVv6n2Qf X-Received: by 10.237.35.201 with SMTP id k9mr2795308qtc.92.1470262955642; Wed, 03 Aug 2016 15:22:35 -0700 (PDT) Received: from [192.168.8.100] ([181.201.246.7]) by smtp.gmail.com with ESMTPSA id n143sm5301571qkn.27.2016.08.03.15.22.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 Aug 2016 15:22:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Wed, 3 Aug 2016 18:22:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ulrich Herberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] draft-ietf-oauth-native-apps-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: Wed, 03 Aug 2016 22:22:39 -0000 Sorry I missed your comments. Inline > On Apr 4, 2016, at 1:09 PM, Ulrich Herberg = wrote: >=20 > Hi, >=20 > I have read draft-ietf-oauth-native-apps-01 and I generally agree with > the overall recommendations in the draft, and it is well written (I > haven't participated in this WG before, so I don't know what to what > level it has already been discussed). >=20 > Some comments: > - Section 2, last paragraph: > I agree with the general recommendation to not use an external user > agent because of complexity. However, there are cases when a tablet is > sold as a closed system and under full control of the vendor. In these > cases, the vendor can preinstall the AS user agent into the operating > system and provide APIs for other apps to use it. >=20 Yes that is possable but this document is not describing how to use such = an external token agent. =20 That needs to be a separate spec. We did start one called NAPPS in the = OpenID foundation but have largely abandoned it due to to the complexity = of also needing to change OAuth to support that model. It can be done but so far only in a relatively closed environment. For = applications that need to work with multiple authentication servers the = model of doing OAuth via a system browser seems the most strait-forward. = =20 We are recommending not doing it and saying if you want to it is out of = scope. If you have some specific text you would like to see let us = know. >=20 > - Section 5.1 (Embedded User-agents): "Authorization servers SHOULD > consider taking steps to detect and block logins via embedded > user-agents that are not their own, where possible." >=20 > Do you have any recommendation how to do that, other than reading the > (easily modifiable) User-Agent HTTP header? Maybe you could add a > sentence for providing some guidance here. At the moment looking at the browser strings and blacklisting client id = of apps that fake them is the only thing we have at the moment. I think Google is currently looking into this and William may have more = information. >=20 >=20 > - Section 5.3 (Phishing): > This is indeed concerning; it's very easy to fake the in-app browser. > The draft says: "If all native apps use the techniques described in > this best practice, users will not need to sign-in frequently and thus > should be suspicious of any sign-in request when they should have > already been signed-in." >=20 > That is true, in theory, but sounds like a big "if" to me. Most users > are not savvy enough to be suspicious if a login screen appears and it > looks the same as the one they know. > I admit that I don't have any suggestion how to do it better, but this > part seems to be the most problematic to me for using OAuth on native > devices. I don=E2=80=99t think we have any magic bullet for fake apps.=20 There are some techniques to cookie the browser with the users photo or = other information that will be harder to fake outside the real browser. Un-phishable credentials like Fido may be the only long term answer for = this, but at least this recommendation of using the system or external = browser make using Fido possable where U2F atleast is blocked from = webviews currently. John B. >=20 > Best regards > Ulrich >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Aug 3 15:30:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E2A12D125 for ; Wed, 3 Aug 2016 15:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VECRKknj7Op for ; Wed, 3 Aug 2016 15:30:09 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 271FC12B009 for ; Wed, 3 Aug 2016 15:30:09 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id w38so151586969qtb.0 for ; Wed, 03 Aug 2016 15:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=orrwqay9UIVehTOFxUyyzxhVTF/snWgNehBafoCnyGo=; b=Wrz946feIgbR75TW1JVRWONFkLehbWgdk9vliL1ux5rUarg3NVgou8yHa0kaffU2Mo 0wHj/J2yctVOAvsWi8kwoxPv/R++Gf9bDrRzU4DudVgMx0Vo+PmK0aMKrU5AN1x3hKzy eBPgyO9Y4oxEkw+ypj96rUYHWeufg3fKJOACax7g/VxFT452tLLAGknbcemjYRCjv08F 7lf6W6vPyPFCeDF4mMcUt1waA3NoGyj3EVwWIfNiuLLL3Ie+aFXvkWeruS4z5FGbfTI4 2pNM2DZ/4seewCo5KEGvEpelX9HEiBWhNEudtGKZFhpZixxOxWmL3UnrJneRJ8GQm9tP ReKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=orrwqay9UIVehTOFxUyyzxhVTF/snWgNehBafoCnyGo=; b=BQiNT+xvTWzy7SnbzJp1ecD2SSjq2LRlgn/Z4RFiZoSqsbSvwIBE6bvBsPLfZFEW7n PKlK1oNze/a+ACefTG/AY0A5zT1MWZcdAGnHGcD9jypFb61HZO5XGJbjfM3F6IXLzwnS xRy9msorfyBqw6VtxOi4I/nVk3ltWOGAQQfIBhY3E0r4/Nhr6JO0FP0Kyk0asJWWajLa pMfRHCuf5NLqOI7Rc0WDGn+9KlYbxZyR7hHR9xTu7fGMnJBfYqbvrF/RK5+3fygL4DFs hl5Blge05YBskFdev3G5Us0nYc7K4M5hL9+JrFeWuKB9NFy7rJ/ZU+AMh+WKhtUfEGU+ DKBQ== X-Gm-Message-State: AEkoouteJ6MMCbDWyku6jtBbsETFQ2DXC6VUgd0XNNF0mx7T//2K2e7k/hnS6Kd39UII2TUw X-Received: by 10.200.38.107 with SMTP id v40mr2879158qtv.76.1470263408085; Wed, 03 Aug 2016 15:30:08 -0700 (PDT) Received: from [192.168.8.100] ([181.201.246.7]) by smtp.gmail.com with ESMTPSA id 123sm5278514qkl.41.2016.08.03.15.30.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 03 Aug 2016 15:30:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Wed, 3 Aug 2016 18:30:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1A386E9C-D198-495C-B1F2-B8A986915FEA@ve7jtb.com> References: To: Ulrich Herberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-native-apps-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: Wed, 03 Aug 2016 22:30:11 -0000 Inline > On Apr 15, 2016, at 1:10 AM, Ulrich Herberg = wrote: >=20 > Hi, >=20 > I was wondering if you had any thoughts about my comments below from > my other email? >=20 > In addition, I was wondering about the case where the client ID and > client secret of an app has been leaked. The draft mentions the case > where a rogue app intercepts the auth code by using the same redirect > URL scheme of another app and how to mitigate that with PKCE. > But how could you prevent the rogue app from pretending to be another > app in case it got hold of the Client ID and Client Secret of that > app? In that case, couldn't it initiate the auth request (and thereby > pass the PKCE verification correctly)? >=20 This spec is not intended to stop app impersonation. PKCE os no help with this. William and I are also working on an attestation spec that will allow = the OS to attest to an applications developer key and bundle ID. To do that securely we want to use token binding to bind the attestation = to the app making the call to a token endpoint. It is different enough, and has a number of dependencies on new work = that we did not want to block getting these best practices out, on new = work. I agree that app impersonation will become a real problem, but one step = at a time. John B. > Thanks > Ulrich >=20 > On Mon, Apr 4, 2016 at 10:09 AM, Ulrich Herberg = wrote: >> Hi, >>=20 >> I have read draft-ietf-oauth-native-apps-01 and I generally agree = with >> the overall recommendations in the draft, and it is well written (I >> haven't participated in this WG before, so I don't know what to what >> level it has already been discussed). >>=20 >> Some comments: >> - Section 2, last paragraph: >> I agree with the general recommendation to not use an external user >> agent because of complexity. However, there are cases when a tablet = is >> sold as a closed system and under full control of the vendor. In = these >> cases, the vendor can preinstall the AS user agent into the operating >> system and provide APIs for other apps to use it. >>=20 >>=20 >> - Section 5.1 (Embedded User-agents): "Authorization servers SHOULD >> consider taking steps to detect and block logins via embedded >> user-agents that are not their own, where possible." >>=20 >> Do you have any recommendation how to do that, other than reading the >> (easily modifiable) User-Agent HTTP header? Maybe you could add a >> sentence for providing some guidance here. >>=20 >>=20 >> - Section 5.3 (Phishing): >> This is indeed concerning; it's very easy to fake the in-app browser. >> The draft says: "If all native apps use the techniques described in >> this best practice, users will not need to sign-in frequently and = thus >> should be suspicious of any sign-in request when they should have >> already been signed-in." >>=20 >> That is true, in theory, but sounds like a big "if" to me. Most users >> are not savvy enough to be suspicious if a login screen appears and = it >> looks the same as the one they know. >> I admit that I don't have any suggestion how to do it better, but = this >> part seems to be the most problematic to me for using OAuth on native >> devices. >>=20 >> Best regards >> Ulrich >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Aug 3 20:55:03 2016 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BAD12D647; Wed, 3 Aug 2016 20:54:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160804035457.9671.15892.idtracker@ietfa.amsl.com> Date: Wed, 03 Aug 2016 20:54:57 -0700 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.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: Thu, 04 Aug 2016 03:54:58 -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 JWT Authorization Request (JAR) Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-08.txt Pages : 21 Date : 2016-08-03 Abstract: The authorization request in OAuth 2.0 [RFC6749] 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 authentciated. 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 confidentiallity 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-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 4 03:00:04 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CEC12D97A for ; Thu, 4 Aug 2016 03:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 owM3b9hUKzeD for ; Thu, 4 Aug 2016 02:59:58 -0700 (PDT) Received: from p3plsmtpa11-01.prod.phx3.secureserver.net (p3plsmtpa11-01.prod.phx3.secureserver.net [68.178.252.102]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCE812D972 for ; Thu, 4 Aug 2016 02:59:09 -0700 (PDT) Received: from [192.168.19.103] ([109.160.89.229]) by p3plsmtpa11-01.prod.phx3.secureserver.net with id Sxz61t0064wu8xH01xz7YL; Thu, 04 Aug 2016 02:59:09 -0700 To: oauth@ietf.org References: <20160804035457.9671.15892.idtracker@ietfa.amsl.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <102ec164-bc1a-cc35-820b-fa9ceb237b1c@connect2id.com> Date: Thu, 4 Aug 2016 12:59:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160804035457.9671.15892.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050003040506070806050307" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.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, 04 Aug 2016 10:00:01 -0000 This is a cryptographically signed message in MIME format. --------------ms050003040506070806050307 Content-Type: multipart/alternative; boundary="------------B48C6E3BFCB03A64DCAA4081" This is a multi-part message in MIME format. --------------B48C6E3BFCB03A64DCAA4081 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Nat. It looks like draft-ietf-oauth-jwsreq-08.txt is breaking with OpenID Connect in regard to 1. alg:none request JWTs being no longer permitted 2. HTTPS request_uri's becoming always required, though there is confusion about that (see below). I don't know if this is intentional. Quoting the original Connect spec on alg:none: http://openid.net/specs/openid-connect-core-1_0.html#RequestObject ``` The Request Object MAY be signed or unsigned (plaintext). When it is plaintext, this is indicated by use of the none algorithm [JWA] in the JOSE Header. ``` There is also confusion about the requirement to have HTTPS, which in 5.2 is conditionally required, and in 5.2.1 always required (the 5.2.1 edit appeared in -08). https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2 ``` The contents of the resource referenced by the URL MUST be a Request Object. The scheme used in the "request_uri" value MUST be "https", unless the target Request Object is signed in a way that is verifiable by the Authorization Server.=20 ``` https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2.1 ``` The URL MUST be HTTPS URL. ``` Cheers, Vladimir --=20 Vladimir Dzhuvinov --------------B48C6E3BFCB03A64DCAA4081 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Nat.

It looks like draft-ietf-oauth-jwsreq-08.txt is breaking with OpenID Connect in regard to

1. alg:none request JWTs being no longer permitted

2. HTTPS request_uri's becoming always required, though there is confusion about that (see below).


I don't know if this is intentional.



Quoting the original Connect spec on alg:none:

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

```
The Request Object MAY be signed or unsigned (plaintext). When it is plaintext, this is indicated by use of the<= span class=3D"Apple-converted-space">=A0none=A0algorithm=A0[JWA]=A0in the JOSE Header.
```
<= /span>

<= /span>There is also confusion about the requirement to have HTTPS, which in 5.2 is conditionally required, and in 5.2.1 always required (the 5.2.1 edit appeared in -08).

https://tools.ietf.org/html/dra= ft-ietf-oauth-jwsreq-08#section-5.2

```
The contents of the resource referenced by the=
 URL MUST be a Request
Object.  The scheme used in the "request_uri" value MUST be "https",
unless the target Request Object is signed in a way that is
verifiable by the Authorization Server.=20
```

<= /span>https://tools.ietf.org/html= /draft-ietf-oauth-jwsreq-08#section-5.2.1

```
The URL MUST be HTTPS URL.
```


Cheers,

Vladimir
<= /span>
<= /span>
--
Vladimir Dzhuvinov --------------B48C6E3BFCB03A64DCAA4081-- --------------ms050003040506070806050307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhBvIAvByRn0gXptBJbNZg3jMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTYwNDA1MDAwMDAwWhcNMTcwNDA1MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAL/GlaryvhrL+eLYe+8Pv6D/sITLb5c2D5oaq6drPbcqP06xnyLgeFlIwzshIHi5+/Ib fwSSXRzCDihXBfPlbv2Yf7C0F7QwUYNnqvxfnIZvu/6YFXkWt6Z5h5wvnbFmHWZBiBM8cEMP qdT7myXDKuHSYvpiCFnIAHJOeoyBRV1I8kyupPe9aBkcYmwAyMjMRgeR92iV4TfTSx4CMRax OHwa+WUAc2mjWiZOxyxTByORzm2wB2izX/DoeSwcN9mliRAZQ3eBXQD/HoO0LBIX3MXCp9Ry wHIhz+Qy3mR0VgUu2gGu1r0lLIGwxKE4kEO1I7aBf5hQK/wVKcMyMMpNnU0CAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSCdqr1QGt7 r/f9VkCCmYSI3t5aDjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAFClbz5g+/TKUP9zpmoRdZymgYrU fgq1UlnzLcgI3IH46LaMMMzUCRn7tz8OM2igQEqpSW9u80W3jaYsRLUdySvE6Jxr9xVPVDGu JMAenNDS3sgNsKvUcCIeQYYTG4/oYTcuV6jtXTSDK0Y8NQ0pNEg8BnQz3V+nPXYC3/CWoFQ+ 4InVPLGTZedK+yev6ee6wWWL3neskkSsYpwW1qTWtjHQcNw2eBphxRq5aNM9F3wKGdkUHKUJ 4mof2ckALH5SO/n0GGR58cgrtfuD/fcqvfsTtiMCHk6oW2ZE5Ty93aDvEhYo5RrA0TpFGoOA m33FY3lP8EGzGel61qKU5nDH1hUxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBvIAvByRn0gXptBJbNZg3jMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA4MDQwOTU5MDVaMC8GCSqGSIb3DQEJBDEiBCDlJJ8OyEXFDETpS3XyE0HYgmqzToum tZa+pToZ4hysTDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQAGM5pNaltt NNVlSW1XEM0mEF6OVO+49AzbT6feGr2HvgSHXsJjmfoudm6Osh2H4PAj09P8cw2FtyxVWb1h X+n7h7/L3VTPbgKoBfZHGUnTBNmXVdYtM55c2V/sWlIQxef1FiSGyq4ZBPOYNYi9SEO6jYa5 /T6kePAFvoLDXTMSGYj/HRvgShG4XTuE7ubfzqCqgkpv/VFk2xiJnkdfhXdvCPBP9pGNv/s5 uGqfUQYFBmMXpnXlNJY7O851KBXMLLpZmlxwvFHIMIPWQNoElvRJ5q9U8nit8sl2xshgNOx4 RhhVTkVxQTPKAkDqagSmPicwbZEjxdOix9cVOUzH82I6AAAAAAAA --------------ms050003040506070806050307-- From nobody Thu Aug 4 03:14:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BE112D9D1 for ; Thu, 4 Aug 2016 03:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 QnRiwfXV8w-D for ; Thu, 4 Aug 2016 03:14:46 -0700 (PDT) Received: from p3plsmtpa07-02.prod.phx3.secureserver.net (p3plsmtpa07-02.prod.phx3.secureserver.net [173.201.192.231]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691C912D9E4 for ; Thu, 4 Aug 2016 03:14:42 -0700 (PDT) Received: from [192.168.19.103] ([109.160.89.229]) by p3plsmtpa07-02.prod.phx3.secureserver.net with id SyEf1t00E4wu8xH01yEh8B; Thu, 04 Aug 2016 03:14:42 -0700 To: oauth@ietf.org References: <20160804035457.9671.15892.idtracker@ietfa.amsl.com> <102ec164-bc1a-cc35-820b-fa9ceb237b1c@connect2id.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <63052b93-b6f4-798b-2774-fa708d5a66af@connect2id.com> Date: Thu, 4 Aug 2016 13:14:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <102ec164-bc1a-cc35-820b-fa9ceb237b1c@connect2id.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030506030006040408000602" Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.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, 04 Aug 2016 10:14:47 -0000 This is a cryptographically signed message in MIME format. --------------ms030506030006040408000602 Content-Type: multipart/alternative; boundary="------------C851DC4778074A08A1E8CE02" This is a multi-part message in MIME format. --------------C851DC4778074A08A1E8CE02 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would like to propose a slight change of the spec title. From *OAuth 2.0 JWT Authorization Request* to *JSON Web Token (JWT) Secured OAuth 2.0 Authorization Request* The current title is not particularly descriptive, and may even read as if the spec is about requesting a JWT. Thanks, Vladimir --=20 Vladimir Dzhuvinov --------------C851DC4778074A08A1E8CE02 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I would like to propose a slight change of the spec title.


From

OAuth 2.0 JWT Authorization Request


to

JSON Web Token (JWT) Secured OAuth 2.0 Authorization Request


The current title is not particularly descriptive, and may even read as if the spec is about requesting a JWT.


Thanks,


Vladimir



--=20
Vladimir Dzhuvinov
--------------C851DC4778074A08A1E8CE02-- --------------ms030506030006040408000602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhBvIAvByRn0gXptBJbNZg3jMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTYwNDA1MDAwMDAwWhcNMTcwNDA1MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAL/GlaryvhrL+eLYe+8Pv6D/sITLb5c2D5oaq6drPbcqP06xnyLgeFlIwzshIHi5+/Ib fwSSXRzCDihXBfPlbv2Yf7C0F7QwUYNnqvxfnIZvu/6YFXkWt6Z5h5wvnbFmHWZBiBM8cEMP qdT7myXDKuHSYvpiCFnIAHJOeoyBRV1I8kyupPe9aBkcYmwAyMjMRgeR92iV4TfTSx4CMRax OHwa+WUAc2mjWiZOxyxTByORzm2wB2izX/DoeSwcN9mliRAZQ3eBXQD/HoO0LBIX3MXCp9Ry wHIhz+Qy3mR0VgUu2gGu1r0lLIGwxKE4kEO1I7aBf5hQK/wVKcMyMMpNnU0CAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSCdqr1QGt7 r/f9VkCCmYSI3t5aDjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAFClbz5g+/TKUP9zpmoRdZymgYrU fgq1UlnzLcgI3IH46LaMMMzUCRn7tz8OM2igQEqpSW9u80W3jaYsRLUdySvE6Jxr9xVPVDGu JMAenNDS3sgNsKvUcCIeQYYTG4/oYTcuV6jtXTSDK0Y8NQ0pNEg8BnQz3V+nPXYC3/CWoFQ+ 4InVPLGTZedK+yev6ee6wWWL3neskkSsYpwW1qTWtjHQcNw2eBphxRq5aNM9F3wKGdkUHKUJ 4mof2ckALH5SO/n0GGR58cgrtfuD/fcqvfsTtiMCHk6oW2ZE5Ty93aDvEhYo5RrA0TpFGoOA m33FY3lP8EGzGel61qKU5nDH1hUxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBvIAvByRn0gXptBJbNZg3jMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA4MDQxMDE0MzhaMC8GCSqGSIb3DQEJBDEiBCDXB0/TlWKZ1jk/O+68cpoQRyurPQlJ Kv5fi6JA1/1t8DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQA7BX0t//Ny Z97eX0PvTS5xr39hbxNAarwP+4QRoywk934jC46Q3nVln1rtIpkqCu+Xy53U/aaAJrmXoy7C WC1q2UWc+WC2Bs0ZpdtVxhrS0l7sRKIpDmhnJiiNqhFLUJn3H4+qeNLZ8JTlWJLXjiyqkP1u 6XbNboG6TGR8hkpfrf+o3W1X0ar9ltuXTWrsRVzrOalTeqJt4xvRIfb5MTFcES4RKnoCtRzG xWi038oktHtod04Xx8PBrjonvuXxZUi8DwixEtrpJ+gMdtGf37hobOj1yaTQIgd2JG3PWnb2 lw5KttUT72/UmAVAY/hDZPySsAAc9rqQoH1YMHZDUK3rAAAAAAAA --------------ms030506030006040408000602-- From nobody Thu Aug 4 03:18:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D635212D976 for ; Thu, 4 Aug 2016 03:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 ZF8yPXaOI18x for ; Thu, 4 Aug 2016 03:18:32 -0700 (PDT) Received: from p3plsmtpa07-05.prod.phx3.secureserver.net (p3plsmtpa07-05.prod.phx3.secureserver.net [173.201.192.234]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC55B12D658 for ; Thu, 4 Aug 2016 03:18:28 -0700 (PDT) Received: from [192.168.19.103] ([109.160.89.229]) by p3plsmtpa07-05.prod.phx3.secureserver.net with id SyJS1t0044wu8xH01yJTCc; Thu, 04 Aug 2016 03:18:28 -0700 To: oauth@ietf.org References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: Date: Thu, 4 Aug 2016 13:18:25 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <33052033-0992-ceb8-4390-6837017b140e@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090108050201090906010303" Archived-At: Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0 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, 04 Aug 2016 10:18:34 -0000 This is a cryptographically signed message in MIME format. --------------ms090108050201090906010303 Content-Type: multipart/alternative; boundary="------------DD3E41C8325B88A42CB2018F" This is a multi-part message in MIME format. --------------DD3E41C8325B88A42CB2018F Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree to have these specs accepted. On 03/08/16 10:45, Hannes Tschofenig wrote: > Hi all, > > this is the call for adoption of the 'OAuth 2.0 Token Binding' document= > bundle* following the positive call for adoption at the recent IETF > meeting in Berlin. > > Here are the links to the documents presented at the last IETF meeting:= > https://tools.ietf.org/html/draft-jones-oauth-token-binding-00 > https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 > > Please let us know by August 17th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Ciao > Hannes & Derek > > *: We will find out what the best document structure is later, i.e., > whether the content should be included in one, two or multiple document= s. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov --------------DD3E41C8325B88A42CB2018F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I agree to have these specs accepted.


On 03/08/16 10:45, Hannes Tschofenig wrote:
Hi all,

this is the call for adoption of the 'OAuth 2.0 Token Binding' document
bundle* following the positive call for adoption at the recent IETF
meeting in Berlin.

Here are the links to the documents presented at the last IETF meeting:
https://tools.ietf.org/html/draft-jones=
-oauth-token-binding-00
https://tools.ietf.org/html/draft-campbell-=
oauth-tbpkce-00

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

Ciao
Hannes & Derek

*: We will find out what the best document structure is later, i.e.,
whether the content should be included in one, two or multiple documents.=





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


--=20
Vladimir Dzhuvinov
--------------DD3E41C8325B88A42CB2018F-- --------------ms090108050201090906010303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhBvIAvByRn0gXptBJbNZg3jMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTYwNDA1MDAwMDAwWhcNMTcwNDA1MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAL/GlaryvhrL+eLYe+8Pv6D/sITLb5c2D5oaq6drPbcqP06xnyLgeFlIwzshIHi5+/Ib fwSSXRzCDihXBfPlbv2Yf7C0F7QwUYNnqvxfnIZvu/6YFXkWt6Z5h5wvnbFmHWZBiBM8cEMP qdT7myXDKuHSYvpiCFnIAHJOeoyBRV1I8kyupPe9aBkcYmwAyMjMRgeR92iV4TfTSx4CMRax OHwa+WUAc2mjWiZOxyxTByORzm2wB2izX/DoeSwcN9mliRAZQ3eBXQD/HoO0LBIX3MXCp9Ry wHIhz+Qy3mR0VgUu2gGu1r0lLIGwxKE4kEO1I7aBf5hQK/wVKcMyMMpNnU0CAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSCdqr1QGt7 r/f9VkCCmYSI3t5aDjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAFClbz5g+/TKUP9zpmoRdZymgYrU fgq1UlnzLcgI3IH46LaMMMzUCRn7tz8OM2igQEqpSW9u80W3jaYsRLUdySvE6Jxr9xVPVDGu JMAenNDS3sgNsKvUcCIeQYYTG4/oYTcuV6jtXTSDK0Y8NQ0pNEg8BnQz3V+nPXYC3/CWoFQ+ 4InVPLGTZedK+yev6ee6wWWL3neskkSsYpwW1qTWtjHQcNw2eBphxRq5aNM9F3wKGdkUHKUJ 4mof2ckALH5SO/n0GGR58cgrtfuD/fcqvfsTtiMCHk6oW2ZE5Ty93aDvEhYo5RrA0TpFGoOA m33FY3lP8EGzGel61qKU5nDH1hUxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBvIAvByRn0gXptBJbNZg3jMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA4MDQxMDE4MjVaMC8GCSqGSIb3DQEJBDEiBCDYUFDtzFBPJjYSbAkhyD9DoB0HnZWN c4uObg9DM3MD9TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQADCidb2bAw BWL6jGew4mpuz+NzQf/iJSI/KmlH4El+JpNFhsnYr4KaWHyb6FakNsI25yzsGxkbrcSMqhNR UMjQ/vSapJtBE9nI2OJZ5BfSXbkA07Z8EkZBP/Hy7rfp6YBiSQIS6MZCf4QG3D3vOr8diPDS EKRR9Y0KjOY55RucI5QG/32QD+Pz3Y9nYj/meE5yGjoPuG5jICQiI46O2eI0yErZs0QYu+l9 4Cl1XF0F5rFjOV3UM+He/euh+vZ8rpFhVw/O52OHaBOukZ4fqM5i1Z+nDM21KDyzfR/aCNkE u3f+RZDJzln1H4Ue78fVT4Gt4zBeO2KX0CgBgyvw4aBtAAAAAAAA --------------ms090108050201090906010303-- From nobody Thu Aug 4 03:33:48 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D083F12DA33 for ; Thu, 4 Aug 2016 03:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 p2EBZC8I9z3U for ; Thu, 4 Aug 2016 03:33:44 -0700 (PDT) Received: from p3plsmtpa12-05.prod.phx3.secureserver.net (p3plsmtpa12-05.prod.phx3.secureserver.net [68.178.252.234]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF42B12D9FD for ; Thu, 4 Aug 2016 03:33:44 -0700 (PDT) Received: from [192.168.19.103] ([109.160.89.229]) by p3plsmtpa12-05.prod.phx3.secureserver.net with id SyZi1t0034wu8xH01yZjVV; Thu, 04 Aug 2016 03:33:44 -0700 To: oauth@ietf.org References: From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <52f75ab0-9072-49dd-635b-da5de4014312@connect2id.com> Date: Thu, 4 Aug 2016 13:33:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090009030306050108050104" Archived-At: Subject: Re: [OAUTH-WG] OAuth Metadata Specifications Enhanced 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, 04 Aug 2016 10:33:47 -0000 This is a cryptographically signed message in MIME format. --------------ms090009030306050108050104 Content-Type: multipart/alternative; boundary="------------0BD468204BD6D126C037A170" This is a multi-part message in MIME format. --------------0BD468204BD6D126C037A170 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Mike for the updates. These two specs (along with token exchange and perhaps others) effectively codify "resource" as a key OAuth 2.0 property and parameter, alongside "scope". RFC 6749 however only specifies "scope" in authz and token requests. Have there been any thoughts how to reconcile this? Vladimir On 03/08/16 23:57, Mike Jones wrote: > The existing OAuth 2.0 Authorization Server Metadata specification has now been joined= by a related OAuth 2.0 Protected Resource Metadata specification. This means th= at JSON metadata formats are now defined for all the OAuth 2.0 parties: c= lients, authorization servers, and protected resources. > > The most significant addition to the OAuth 2.0 Authorization Server Met= adata specification is enabling signed metadata, represented as claims in= a JSON Web Token (JWT). This is analogous to the role that the Software= Statement plays in OAuth Dynamic Client Registration. Signed metadata c= an also be used for protected resource metadata. > > For use cases in which the set of protected resources used with an auth= orization server are enumerable, the authorization server metadata specif= ication now defines the "protected_resources" metadata value to list them= =2E Likewise, the protected resource metadata specification defines an "= authorization_servers" metadata value to list the authorization servers t= hat can be used with a protected resource, for use cases in which those a= re enumerable. > > The specifications are available at: > > * http://tools.ietf.org/html/draft-ietf-oauth-discovery-04 > > * http://tools.ietf.org/html/draft-jones-oauth-resource-metadata-= 00 > > HTML-formatted versions are also available at: > > * http://self-issued.info/docs/draft-ietf-oauth-discovery-04.html= > > * http://self-issued.info/docs/draft-jones-oauth-resource-metadat= a-00.html > > -- Mike > > P.S. This notice was also posted at http://self-issued.info/?p=3D1591 = and as @selfissued. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov --------------0BD468204BD6D126C037A170 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Thanks Mike for the updates.

These two specs (along with token exchange and perhaps others) effectively codify "resource" as a key OAuth 2.0 property and parameter, alongside "scope". RFC 6749 however only specifies "scope" in authz and token requests.

Have there been any thoughts how to reconcile this?

Vladimir


On 03/08/16 23:57, Mike Jones wrote: 
The existing OAuth 2.0 Authorization Server Metadata=
<https://tools.ietf.org/html/draft-ietf-oaut=
h-discovery> specification has now been joined by a related OAuth =
2.0 Protected Resource Metadata<htt=
ps://tools.ietf.org/html/draft-jones-oauth-resource-metadata> spec=
ification.  This means that JSON metadata formats are now defined for all=
 the OAuth 2.0 parties: clients, authorization servers, and protected res=
ources.

The most significant addition to the OAuth 2.0 Authorization Server Metad=
ata specification is enabling signed metadata, represented as claims in a=
 JSON Web Token (JWT).  This is analogous to the role that the Software S=
tatement plays in OAuth Dynamic Client Registration.  Signed metadata can=
 also be used for protected resource metadata.

For use cases in which the set of protected resources used with an author=
ization server are enumerable, the authorization server metadata specific=
ation now defines the "protected_resources" metadata value to list them. =
 Likewise, the protected resource metadata specification defines an "auth=
orization_servers" metadata value to list the authorization servers that =
can be used with a protected resource, for use cases in which those are e=
numerable.

The specifications are available at:

*       http://tools.ietf.org/html/draft-ietf=
-oauth-discovery-04

*       http://tools.ietf.org/html/d=
raft-jones-oauth-resource-metadata-00

HTML-formatted versions are also available at:

*       http://self-issued.info/docs/d=
raft-ietf-oauth-discovery-04.html

*       http://self-issued.in=
fo/docs/draft-jones-oauth-resource-metadata-00.html

                                                       -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=3D15=
91 and as @selfissued<https://twitter.com/selfissued>.




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


--=20
Vladimir Dzhuvinov
--------------0BD468204BD6D126C037A170-- --------------ms090009030306050108050104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhBvIAvByRn0gXptBJbNZg3jMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTYwNDA1MDAwMDAwWhcNMTcwNDA1MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAL/GlaryvhrL+eLYe+8Pv6D/sITLb5c2D5oaq6drPbcqP06xnyLgeFlIwzshIHi5+/Ib fwSSXRzCDihXBfPlbv2Yf7C0F7QwUYNnqvxfnIZvu/6YFXkWt6Z5h5wvnbFmHWZBiBM8cEMP qdT7myXDKuHSYvpiCFnIAHJOeoyBRV1I8kyupPe9aBkcYmwAyMjMRgeR92iV4TfTSx4CMRax OHwa+WUAc2mjWiZOxyxTByORzm2wB2izX/DoeSwcN9mliRAZQ3eBXQD/HoO0LBIX3MXCp9Ry wHIhz+Qy3mR0VgUu2gGu1r0lLIGwxKE4kEO1I7aBf5hQK/wVKcMyMMpNnU0CAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSCdqr1QGt7 r/f9VkCCmYSI3t5aDjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAFClbz5g+/TKUP9zpmoRdZymgYrU fgq1UlnzLcgI3IH46LaMMMzUCRn7tz8OM2igQEqpSW9u80W3jaYsRLUdySvE6Jxr9xVPVDGu JMAenNDS3sgNsKvUcCIeQYYTG4/oYTcuV6jtXTSDK0Y8NQ0pNEg8BnQz3V+nPXYC3/CWoFQ+ 4InVPLGTZedK+yev6ee6wWWL3neskkSsYpwW1qTWtjHQcNw2eBphxRq5aNM9F3wKGdkUHKUJ 4mof2ckALH5SO/n0GGR58cgrtfuD/fcqvfsTtiMCHk6oW2ZE5Ty93aDvEhYo5RrA0TpFGoOA m33FY3lP8EGzGel61qKU5nDH1hUxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBvIAvByRn0gXptBJbNZg3jMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjA4MDQxMDMzNDFaMC8GCSqGSIb3DQEJBDEiBCA9hWWVy8oDrOXSn2z376aE6h8iqKAK mbEUoMASLuI1/zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQBlSOA774Qd clqQYmcZ5wuFkEDxGRDB5TRSVJ86Yy8gyL7xb/V99KUHfeQSQeOmAkA0OfOqRMw8TvuLKal2 XUbnGY3t41aFJvrYKQ7E3cU9DkaoKvmhBLvIMWCqD9oT0BrHtYW0E7yBSVqPsBCxmv+Y5yxz liMFibtnWsNbeKuJ7ee9DneaTWyM0QXGJCTLQp5Cyc8uvbdVIgCffMG9pmMZOxlG4sYX2o6I IeTxNTzXNO65WVGa74CuThyrNUvI9kS2x4V/2kxkdDSZnxS6Wq5bDjsyBiQYraLlEC98wn2z N/Kj4FrOi7l4+IvNeASXjboBetSPm4UXzyXtmH0s9FBfAAAAAAAA --------------ms090009030306050108050104-- From nobody Thu Aug 4 04:01:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED8212DD60 for ; Thu, 4 Aug 2016 04:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 AE8lrcFdplYt for ; Thu, 4 Aug 2016 04:01:19 -0700 (PDT) Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AC912DD9B for ; Thu, 4 Aug 2016 04:00:12 -0700 (PDT) Received: from nriea02.index.or.jp (unknown [172.19.246.37]) by nrifs01.index.or.jp (Postfix) with SMTP id 7FC8478025; Thu, 4 Aug 2016 20:00:11 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea02.index.or.jp (unknown) with ESMTP id u74B0Bxt019762; Thu, 4 Aug 2016 20:00:11 +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 u74B0BLj046476; Thu, 4 Aug 2016 20:00:11 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u74B0B8A046475; Thu, 4 Aug 2016 20:00:11 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf12.index.or.jp ([172.100.25.21]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u74B0BgC046472; Thu, 4 Aug 2016 20:00:11 +0900 From: "Nat Sakimura" To: "'Vladimir Dzhuvinov'" , References: <20160804035457.9671.15892.idtracker@ietfa.amsl.com> <102ec164-bc1a-cc35-820b-fa9ceb237b1c@connect2id.com> In-Reply-To: <102ec164-bc1a-cc35-820b-fa9ceb237b1c@connect2id.com> Date: Thu, 4 Aug 2016 20:00:22 +0900 Message-ID: <02cf01d1ee3f$65c8e4f0$315aaed0$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D0_01D1EE8A.D5B39A30" X-Mailer: Microsoft Outlook 15.0 X-MailAdviser: 20141126 Content-Language: ja Thread-Index: AQKWRHCz9KilBlvCi+NGwnZspa1BqQEXSYAEnqcx1yA= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.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, 04 Aug 2016 11:01:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D0_01D1EE8A.D5B39A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Vladimir, Thanks for the quick response and review. > > 1. alg:none request JWTs being no longer permitted > I think it is a bug of the OpenID Connect Core 1.0. Request Object itself can be alg=none in OAuth JAR draft 08 as well. If alg=none, it MUST NOT be passed by value using `request` parameter. It is fine to be that way as long as you pass it by reference. Like OAuth JAR draft-08, OpenID Connect used to have a section dedicated to "Request Object" if I remember correctly. However, during the re-factoring, it was subsumed in "5.5. Requesting Claims using the "claims" Request Parameter" and the statement about allowing alg=none in Request Object that are passed by value sneaked in there. I am going to file a bug report for OpenID Connect on this. Or, do you have any specific use case for keeping "alg=none" for the "passing by value" case? > > 2. HTTPS request_uri's becoming always required, though there is confusion about that (see below). > I should remove the statement in 5.2.1., as it just meant to have repeated what it was said in 5.2. I should also add further condition in 5.2. so that it becomes: ``` unless the target Request Object is signed in a way that is verifiable by the Authorization Server and the channel is protected so that network attacker cannot observe. ``` What do you think? 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. From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir Dzhuvinov Sent: Thursday, August 4, 2016 6:59 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt Thanks Nat. It looks like draft-ietf-oauth-jwsreq-08.txt is breaking with OpenID Connect in regard to 1. alg:none request JWTs being no longer permitted 2. HTTPS request_uri's becoming always required, though there is confusion about that (see below). I don't know if this is intentional. Quoting the original Connect spec on alg:none: http://openid.net/specs/openid-connect-core-1_0.html#RequestObject ``` The Request Object MAY be signed or unsigned (plaintext). When it is plaintext, this is indicated by use of the none algorithm [JWA] in the JOSE Header. ``` There is also confusion about the requirement to have HTTPS, which in 5.2 is conditionally required, and in 5.2.1 always required (the 5.2.1 edit appeared in -08). https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2 ``` The contents of the resource referenced by the URL MUST be a Request Object. The scheme used in the "request_uri" value MUST be "https", unless the target Request Object is signed in a way that is verifiable by the Authorization Server. ``` https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2.1 ``` The URL MUST be HTTPS URL. ``` Cheers, Vladimir -- Vladimir Dzhuvinov ------=_NextPart_000_02D0_01D1EE8A.D5B39A30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Vladimir,

 

Thanks for the quick response and review. =

 

>

> 1. alg:none request JWTs being no longer = permitted

>

 

I think it is a bug of the OpenID Connect Core 1.0. =

 

Request Object itself can be alg=3Dnone in OAuth JAR draft = 08 as well.

 

If alg=3Dnone, it MUST NOT be passed by value using = `request` parameter.

It is fine to be that way as long as you pass it by = reference.

 

Like OAuth JAR draft-08, OpenID Connect used to have a = section dedicated to “Request Object” if I remember = correctly. However, during the re-factoring, it was subsumed in = “5.5.  Requesting Claims using the "claims" Request = Parameter” and the statement about allowing alg=3Dnone in Request = Object that are passed by value sneaked in there. =

 

I am going to file a bug report for OpenID Connect on this. =

 

Or, do you have any specific use case for keeping = “alg=3Dnone” for the “passing by value” = case?


>

> 2. HTTPS request_uri's becoming always required, = though there is confusion about that (see = below).

> 

 

I should remove the statement in 5.2.1., as it just meant = to have repeated what it was said in 5.2.

 

I should also add further condition = in 5.2. so that it becomes:

 

```

unless the target Request Object is = signed in a way that is

verifiable by the Authorization Server and the channel is =

protected = so that network attacker cannot observe.

```

 

What do you think? =

 

Nat

<= o:p> 

--

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.

<= o:p> 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir = Dzhuvinov
Sent: Thursday, August 4, 2016 6:59 PM
To: = oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: = draft-ietf-oauth-jwsreq-08.txt

 

Thanks Nat.

It looks like = draft-ietf-oauth-jwsreq-08.txt is breaking with OpenID Connect in regard = to

1. alg:none request JWTs being no longer permitted

2. = HTTPS request_uri's becoming always required, though there is confusion = about that (see below).

I don't know if this is intentional.



Quoting = the original Connect spec on alg:none:

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

```
The Request Object MAY = be signed or unsigned (plaintext). When it is plaintext, this is = indicated by use of the none algorithm [JWA] in the JOSE Header.
```


There is also = confusion about the requirement to have HTTPS, which in 5.2 is = conditionally required, and in 5.2.1 always required (the 5.2.1 edit = appeared in -08).

https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2=

```

The contents of =
the resource referenced by the URL MUST be a =
Request
Object.  The =
scheme used in the "request_uri" value MUST be =
"https",
unless =
the target Request Object is signed in a way that =
is
verifiable by the =
Authorization Server. 
```


https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2.1=

```

The URL =
MUST be HTTPS URL.

```


Cheers,

Vladimir


-- =
Vladimir Dzhuvinov

------=_NextPart_000_02D0_01D1EE8A.D5B39A30-- From nobody Thu Aug 4 04:10:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD91512DE2B for ; Thu, 4 Aug 2016 04:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 m-Ej2XQsdOjj for ; Thu, 4 Aug 2016 04:10:29 -0700 (PDT) Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2161A12B056 for ; Thu, 4 Aug 2016 04:08:19 -0700 (PDT) Received: from nriea05.index.or.jp (unknown [172.19.246.40]) by nrifs04.index.or.jp (Postfix) with SMTP id 97211472EE2; Thu, 4 Aug 2016 20:08:18 +0900 (JST) Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea05.index.or.jp (unknown) with ESMTP id u74B8I0S014309; Thu, 4 Aug 2016 20:08:18 +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 u74B8ICO040988; Thu, 4 Aug 2016 20:08:18 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u74B8IeO040987; Thu, 4 Aug 2016 20:08:18 +0900 X-Authentication-Warning: nrims00a.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 nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u74B8Imk040984; Thu, 4 Aug 2016 20:08:18 +0900 From: "Nat Sakimura" To: "'Vladimir Dzhuvinov'" , References: <20160804035457.9671.15892.idtracker@ietfa.amsl.com> <102ec164-bc1a-cc35-820b-fa9ceb237b1c@connect2id.com> <63052b93-b6f4-798b-2774-fa708d5a66af@connect2id.com> In-Reply-To: <63052b93-b6f4-798b-2774-fa708d5a66af@connect2id.com> Date: Thu, 4 Aug 2016 20:08:29 +0900 Message-ID: <02d401d1ee40$881b1950$98514bf0$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D5_01D1EE8B.F80420E0" X-Mailer: Microsoft Outlook 15.0 X-MailAdviser: 20141126 Content-Language: ja Thread-Index: AQKWRHCz9KilBlvCi+NGwnZspa1BqQEXSYAEANW3CJ+eoI8EsA== Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.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, 04 Aug 2016 11:10:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D5_01D1EE8B.F80420E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi. I am open to change, but I would like to have a nice abbreviation as well. What about the following? The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) 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. From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir Dzhuvinov Sent: Thursday, August 4, 2016 7:15 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt I would like to propose a slight change of the spec title. From OAuth 2.0 JWT Authorization Request to JSON Web Token (JWT) Secured OAuth 2.0 Authorization Request The current title is not particularly descriptive, and may even read as if the spec is about requesting a JWT. Thanks, Vladimir -- Vladimir Dzhuvinov ------=_NextPart_000_02D5_01D1EE8B.F80420E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

H= i.

<= o:p> 

I= am open to change, but I would like to have a nice abbreviation as = well.

<= o:p> 

W= hat about the following?

<= o:p> 

T= he OAuth 2.0 Authorization Framework: JWT Secured Authorization Request = (JAR)

<= o:p> 

B= est,

<= o:p> 

N= at

<= o:p> 

--

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.

<= o:p> 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir = Dzhuvinov
Sent: Thursday, August 4, 2016 7:15 PM
To: = oauth@ietf.org
Subject: Re: [OAUTH-WG] I-D Action: = draft-ietf-oauth-jwsreq-08.txt

 

I would = like to propose a slight change of the spec = title.

 

From

OAuth = 2.0 JWT Authorization Request

 

to =

JSON Web Token (JWT) = Secured OAuth 2.0 Authorization Request

 

The = current title is not particularly descriptive, and may even read as if = the spec is about requesting a JWT.

 

Thanks,

 

Vladimir

 

 

-- =

Vladimir =
Dzhuvinov
------=_NextPart_000_02D5_01D1EE8B.F80420E0-- From nobody Thu Aug 4 04:36:05 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFAB12DE1F for ; Thu, 4 Aug 2016 04:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2l1BZq-9qP8h for ; Thu, 4 Aug 2016 04:36:01 -0700 (PDT) Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C3112E069 for ; Thu, 4 Aug 2016 04:27:34 -0700 (PDT) Received: from nriea04.index.or.jp (unknown [172.19.246.39]) by nrifs01.index.or.jp (Postfix) with SMTP id 52AC878015; Thu, 4 Aug 2016 20:27:34 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea04.index.or.jp (unknown) with ESMTP id u74BRXtg013353; Thu, 4 Aug 2016 20:27:34 +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 u74BRXWL044364; Thu, 4 Aug 2016 20:27:33 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u74BRXWt044363; Thu, 4 Aug 2016 20:27:33 +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 u74BRXvP044360; Thu, 4 Aug 2016 20:27:33 +0900 From: "Nat Sakimura" To: "'Hannes Tschofenig'" , References: <5773D3D1.9070105@gmx.net> In-Reply-To: <5773D3D1.9070105@gmx.net> Date: Thu, 4 Aug 2016 20:27:45 +0900 Message-ID: <02ed01d1ee43$38c37c50$aa4a74f0$@nri.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 X-MailAdviser: 20141126 Content-Language: ja Thread-Index: AQMyR/fGsIJ7Hm2K6QS0aT7HaqWC0Z139ZIw Archived-At: Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-07 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 11:36:04 -0000 Hi Hanness,=20 Apparently, this mail did not go out so here it is ... Hi Hannes,=20 Thanks for the comment.=20 Please see inline below.=20 -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Wednesday, June 29, 2016 10:58 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-07 >=20 > Hi Nat, Hi John, > thanks for your work on draft-ietf-oauth-jwsreq. I would like to get = the document ready for the IESG and have therefore reviewed it. > Despite some minor issues I believe the document is in good shape. > Here are my comments: > ** Introduction > The example request in the introduction is longer than 72 characters. > s/textaual nature/textual nature done > s/The request may be encrypted so that end-to-end confidentiality may = be obtained even if in the case TLS connection is terminated at a = gateway or a similar device. /The request may be encrypted so that = end-to-end confidentiality can be provided even if the TLS connection is = terminated at a gateway. done > FROM: > The request can be signed so that an integrity check can be = implemented. If a suitable algorithm is used for the signing, then it = will provide verification of the client making the request. > TO: 1. The request may be signed so that the signer can be = authenticated and the integrity of the request can be checked. done > There are a few cases that request by reference are useful such as: > FROM: > When it is desirable to reduced the size of transmitted request. Since = we are using application layer security, it may substantially increase = the size of the request particulary in the case of using public key = cryptography. > TO: > When it is desirable to reduce the size of transmitted request. The = use of application layer security increases the size of the request, = particularly when public key cryptography is used. done > You write: > Static signature: The client can make a signed Request Object and put = it at a place that the Authorization Server can access. This may just be = done by a client utility or other process, so that the private key does = not have to reside on the client, simplifying programming. Downside of = it is that the signed portion just become a token. > The downside is that there is that there is no indication of freshness = and I believe this is what you mean by "just became a token". I am not = sure that the term 'static signature' is the right term here. Just = delete the 'Static Signature:'. done > Is the JWT a good match to encode the parameters of the request? Why = don't you just use a regular JSON object and apply the JOSE security = mechanisms to it. We are using regular JSON object and applying the JOSE security = mechanisms (e.g., adding iss, etc.) to create a JWT encoded JWS/JWE.=20 > Section 3: Request Object > You write: " To encrypt, JWE [RFC7516] is used. Note that JWE is = always integrity protected, so if only integrity protection is desired, = JWS signature is not needed. " > I think the last sentence should say: "... if only integrity = protection is desired then JWE is not needed." Here, we are talking about whether to sign+encrypt or encrypt only, = i.e., talking=20 about the difference between the integrity protection and the = potentially legally=20 binding signature. For something to be "signed", the signer has to be = able to=20 find what is being signed. However, if the content was encrypted by the = recipient's key,=20 he cannot find what is in it. As the result, signing over it has not = much value.=20 > You write: > " It can also be signed then encrypted. This is sometimes desired to = reduced the repudiation risk from the point of view of the receiver. In = this case, it MUST be signed then encrypted, with the result being a = Nested JWT, as defined in JWT [RFC7519]. "client_secret > What do you mean by "reduced the repudiation risk"? The repudiation risk here is the risk of the signer start claiming that = he has agreed to sign a statement.=20 > It may help if you reference the example in Appendix A.2 of RFC 7519 = regarding a nest JWT. > You write: > " REQUIRED OAuth 2.0 Authorization Request parameters that are not = included in the Request Object MUST be sent as query parameters. If a = required parameter is missing from both the query parameters and the = Request Object, the request is malformed. " > s/REQUIRED/Required > That's a bit unfortunate that you have to send parameters twice -- = once as query parameters and then again in the request object. Is there = no better way to design this? It is not sending twice. It is saying that if the required parameter is = not sent in the signed object, then it has to be sent as a query = parameter.=20 If it is included in the signed request object, it does not have to be = sent in a query parameter.=20 > Section 4: Authorization Request > You write: > " The authorization request object MAY be signed AND/OR encrypted. " > Why is this sentence needed when you have extensively spoken about = this topic already in earlier chapters? If you include it then write = "The authorization request object MAY be signed and/or encrypted." Just making doubly sure that people reads it.=20 Perhaps it is redundant.=20 > For the entire document I believe it is worthwhile to state in the = terminology section that your usage of the term "signed" means digitally = signing with asymmetric crypto system as well as using a MAC (which is a = symmetric key primitive). For combined cases, we should use "JWS Signature" which is a defined = term in RFC7515 so that siganture (Digital Signature) retains its = meaning.=20 > You write: > " Servers MAY cache the contents of the resources referenced by = Request URIs. If the contents of the referenced resource could ever = change, the URI SHOULD include the base64url encoded SHA-256 hash as = defined in FIPS180-2 [FIPS180-2] of the referenced resource contents as = the fragment component of the URI. If the fragment value used for a URI = changes, that signals the server that any cached value for that URI with = the old fragment value is no longer valid. " > I am not sure what this means. Can you provide an example? OK.=20 At the same time, I feel it would be better just to mandate different = URI=20 rather than asking for this specific mechanism.=20 > You list a couple of restrictions of the request URI below" > " The entire Request URI MUST NOT exceed 512 ASCII characters. There = are three reasons for this restriction. > Many WAP / feature phones do not accept large payloads. The = restriction are typically either 512 or 1024 ASCII characters. >=20 > The maximum URL length supported by older versions of Internet = Explorer is 2083 ASCII characters. >=20 > On a slow connection such as 2G mobile connection, a large URL would = cause the slow response and using such is not advisable from the user = experience point of view. " >=20 > I wonder how relevant they are (given that the size of the URI is = substantially increased due to the use of JWT & the JOSE work). For = example, are there still many WAP phones around that want to use this = mechanism? Are old versions of the Internet Explorer still an issue? The draft, as you may recall, was initially proposed in 2009.=20 Compared to that, we have much less issues with longer URIs.=20 Never-the-less, I would like to point out that this clause is only=20 applicable when you are using Request URI, and in this case,=20 this restriction deos not hart too much, while it would still be=20 useful on 2G networks and legacy infrastructures like ATMs,=20 which could be using Windows Embedded 2009 with IE6.0, which=20 is going to be shipped till 2024.=20 > Is a request by value even an option for a 2g mobile phone? Sure. It can be done on an iPhone on Edge network.=20 > Section 5. Validating JWT-Based Requests > You write: "The Authorization Server MUST return an error if = decryption fails." and "The Authorization Server MUST return an error if = signature validation fails." Could you be a bit more precise about the = error message that is returned? From Section 6 I don't see what the = right error response would be. I have clarified it in the draft.=20 > Section 8. Security Considerations: > FROM: > In addition to the all the security considerations discussed in OAuth > 2.0 [RFC6819], the following security considerations SHOULD be taken = into account. > TO: > In addition to the all the security considerations discussed in OAuth > 2.0 [RFC6819], the following security considerations should be taken = into account. > You write: > " When sending the authorization request object through "request" = parameter, it SHOULD be signed with then considered appropriate = algorithm using [RFC7515]. The "alg=3Dnone" SHOULD NOT be used in such a = case. " > The use cases presented in the document talk about end-to-end security = and signed / encrypted requests. Now, in the security consideration = section it almost appears if there is the possibility that the request = object would not experience any security protection at all. > That does not appear right. It does not make sense to just send the = parameters in a different encoding only, or does it? I would only see a = disadvantage doing that, namely the much larger size. Correct. And that's why it is saying you should not do it.=20 It is rather stupid to do it, but you never know what the developpers = would do.=20 I would agree to strengthen the language that alg=3Dnone MUST NOT be = used, etc.=20 > You write: > " If the request object contains personally identifiable or sensitive = information, the "request_uri" MUST be of one-time use and MUST have = large enough entropy deemed necessary with applicable security policy. = For higher security requirement, using [RFC7516] is = client_secretstrongly recommended. " > Why is this so? Today, we send the same request in OAuth over TLS. Why = is there only a problem with the request_uri and not with sending the = request object? This came around to address privacy concerns if I remember correctly.=20 If a same request URI was used persistently, it was pointed out that a = third party Javascript can find that from browser history and use it to = identify the user.=20 The second sentence "For higher security ... " should probalby a = separate paragraph=20 as it is not directly related to the first sentence.=20 Also, I feel that we should have a separate privacy consideration = section and=20 put them there.=20 > I believe the biggest issue that should be discussed in the security = consideration section is the possibility that the request object may not = be fresh. This introduces the possibility for replay attacks and lowers = the quality of the end-to-end security protection. Right.=20 > It may also be good to motivate the application layer security = mechanisms a bit more. For example, what information is in the request = itself that requires encryption? In OpenID Connect, some of the claims in the request may be sensitive.=20 In pure OAuth context, scope value may be sensitive depending on the = application.=20 Encrypting these will protect leakage to a third party through browser = history etc.=20 > When I looked at the example I noticed the client_id and the absence = of the client_secret. I wonder how the mechanism intersects with the = client_id and the client_secret. If a client has, for example, a public = / private key pair configured then the use of JWS (with those = credentials) would provide much better security than a client_id and a = client_secret. The example only depects the authorization request so client_secret is = not being sent.=20 I agree that public key crypto would give much better security than a=20 client_secret, but this bit is out of scope of this spec.=20 > ** Section 11: References > [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security = (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August = 2008, http://www.rfc-editor.org/info/rfc5246. > Could you reference the TLS BCP instead? = https://tools.ietf.org/html/rfc7525 done.=20 > [FIPS180-2] U.S. Department of Commerce and National Institute of = Standards and Technology, "Secure Hash Signature Standard", FIPS 180-2, = August 2002. > Defines Secure Hash Algorithm 256 (SHA256) > Could you reference RFC 6234 instead? = https://tools.ietf.org/html/rfc6234 > Ciao Hannes -- 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. From nobody Thu Aug 4 06:00:10 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3ABC12D52C for ; Thu, 4 Aug 2016 06:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.077 X-Spam-Level: X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-1.287, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=gluu.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6LSv7a290M8 for ; Thu, 4 Aug 2016 06:00:06 -0700 (PDT) Received: from webmail.gluu.org (webmail.gluu.org [104.130.217.77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA98F12D1A4 for ; Thu, 4 Aug 2016 06:00:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTP id E297AB41D9 for ; Thu, 4 Aug 2016 13:00:04 +0000 (UTC) Authentication-Results: webmail.gluu.org (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=gluu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gluu.org; h= user-agent:message-id:references:in-reply-to:organization :subject:subject:to:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version; s=dkim; t=1470315604; x=1471179605; bh=MoY1ddSQBp p6SU/VyXrHYug7vmAe9aR1lWlORrgapS4=; b=aJZaK3r/LjgceonTGpnFzwTtSJ WiUn95WkT1dEtyN0GEeGyi8eN5echbPJvz8kp37r5ivay6Wprkbchm13CCC4H4xS hcxsHeKdQVJnBdQIwgYx7qwwOMguqAeoVj0O0X6BXZnZ7WousPcjpu7Y2IUd7tMj 8mc65XqgvXy2xPXds= Received: from webmail.gluu.org ([127.0.0.1]) by localhost (webmail.gluu.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0KvcczqX8KS for ; Thu, 4 Aug 2016 13:00:04 +0000 (UTC) Received: from webmail.gluu.org (localhost [127.0.0.1]) by webmail.gluu.org (Postfix) with ESMTPSA id 78E61B40D2 for ; Thu, 4 Aug 2016 13:00:03 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 04 Aug 2016 08:00:03 -0500 From: Mike Schwartz To: oauth@ietf.org Organization: Gluu In-Reply-To: References: Message-ID: X-Sender: mike@gluu.org User-Agent: Roundcube Webmail Archived-At: Subject: Re: [OAUTH-WG] Using IdToken instead of Access token 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, 04 Aug 2016 13:00:09 -0000 Sergey, Since no one answered your question, let me pose a few questions to your questions! Wouldn't it give you more flexibility to issue a different token to represent access to the RS API? In terms of passing user claims, couldn't this be done via parameters in the API? Are you trying to do more with OpenID Connect than was anticpiated in the design? The id_token has an audience, are you including more than one client in that audience? Would it make sense to look at token exchange and downscope the token? If you are looking for a profile of OAuth2, might UMA work? I think you're not alone in wondering what the answer to all these questions are.. - Mike ------------------------------------- Michael Schwartz Gluu http://gluu.org > Message: 3 > Date: Wed, 3 Aug 2016 11:08:29 +0100 > From: Sergey Beryozkin > To: "oauth@ietf.org" > Subject: [OAUTH-WG] Using IdToken instead of Access token > Message-ID: > Content-Type: text/plain; charset=windows-1252; format=flowed > > Hi All > > I hope this question is better suited for this list. Will have no > problems redirecting it to the openid-connect list instead. > > Consider a user working with the client web application (OIDC RP) which > authenticates the user with the OIDC authorization code flow at the end > of which the client gets AccessToken + IdToken. Next the user requests > something from the client which needs to access the RS to complete this > request. > > And the idea is to have the client pass IdToken to RS and use various > user claims inside this IdToken to enforce the access control at the RS > level. My position it is likely wrong but I guess I may be missing > something that will be either in favor or against it. > > The reason I think it is wrong is that if the client is using a code > flow then the right approach for staying within the OAuth2 'world' is > to > use the access token to talk to RS and use IdToken only for the purpose > of interacting with the user. The access token represents a proper user > authorization and can have the extra scopes in addition to "oidc" which > RS can depend upon in its access control restrictions. > > Next I'm arguing that if the IdToken is used instead then it is the > case > of the client impersonating the user. And refer to the STS for the REST > of Us draft (I have a separate series of question on that draft). I'm > saying the impersonation can work but ignoring the access tokens > completely will make the overall solution much less flexible. > > I'd like to ask for some advice/guidance: > > - Is it a good idea at all for the client to use IdToken instead of > AccessToken as explored above ? I suppose it can work, in the code flow > the client gets the access token which, by default, only allows to > access UserInfo. Perhaps the client impersonating IdToken for the > purpose of accessing RS is not too bad after all. > > - Assuming the impersonation is OK, what is the right criteria for the > client to choose to work with IdToken instead of the access token when > accessing the immediate RS. It seems like if the impersonation is OK > for > the client to do then why have access tokens at all... > > - Assuming the impersonation is OK, does STS For the REST of Us shows > the right and the only way it needs to be done ? I can imagine how it > will work for the web app clients, but what about Implicit Clients. > > Many thanks, Sergey > > > From nobody Thu Aug 4 07:01:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABDD12D595 for ; Thu, 4 Aug 2016 07:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 EvEsaLkWng78 for ; Thu, 4 Aug 2016 07:01:16 -0700 (PDT) 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 89C5D12D91D for ; Thu, 4 Aug 2016 07:01:12 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u74E19VQ024665 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2016 14:01:10 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u74E19o5017333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2016 14:01:09 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u74E17qX030184; Thu, 4 Aug 2016 14:01:08 GMT Received: from [100.44.135.164] (/100.44.135.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Aug 2016 07:01:06 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Thu, 4 Aug 2016 07:01:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8F94CB33-41A6-438E-BE15-38A90FE653F5@oracle.com> References: To: Mike Schwartz X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Using IdToken instead of Access token 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, 04 Aug 2016 14:01:23 -0000 You might be munging two different flows with different semantics together.=20= First flow is use oidc to authen the user to the client.=20 Second flow is normal oauth authorization to get an at to access the resourc= e.=20 Often the OP AS is different from the RS's AS and the rs needs a proper "del= egation" access token.=20 Phil > On Aug 4, 2016, at 6:00 AM, Mike Schwartz wrote: >=20 > Sergey, >=20 > Since no one answered your question, let me pose a few questions to your q= uestions! >=20 > Wouldn't it give you more flexibility to issue a different token to > represent access to the RS API? In terms of passing user claims, > couldn't this be done via parameters in the API? Are you trying to do > more with OpenID Connect than was anticpiated in the design? > The id_token has an audience, are you including more than one client in th= at > audience? Would it make sense to look at token exchange and downscope the t= oken? > If you are looking for a profile of OAuth2, might UMA work? >=20 > I think you're not alone in wondering what the answer to all these questio= ns are.. >=20 > - Mike >=20 >=20 > ------------------------------------- > Michael Schwartz > Gluu > http://gluu.org >=20 >> Message: 3 >> Date: Wed, 3 Aug 2016 11:08:29 +0100 >> From: Sergey Beryozkin >> To: "oauth@ietf.org" >> Subject: [OAUTH-WG] Using IdToken instead of Access token >> Message-ID: >> Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed >> Hi All >> I hope this question is better suited for this list. Will have no >> problems redirecting it to the openid-connect list instead. >> Consider a user working with the client web application (OIDC RP) which >> authenticates the user with the OIDC authorization code flow at the end >> of which the client gets AccessToken + IdToken. Next the user requests >> something from the client which needs to access the RS to complete this >> request. >> And the idea is to have the client pass IdToken to RS and use various >> user claims inside this IdToken to enforce the access control at the RS >> level. My position it is likely wrong but I guess I may be missing >> something that will be either in favor or against it. >> The reason I think it is wrong is that if the client is using a code >> flow then the right approach for staying within the OAuth2 'world' is to >> use the access token to talk to RS and use IdToken only for the purpose >> of interacting with the user. The access token represents a proper user >> authorization and can have the extra scopes in addition to "oidc" which >> RS can depend upon in its access control restrictions. >> Next I'm arguing that if the IdToken is used instead then it is the case >> of the client impersonating the user. And refer to the STS for the REST >> of Us draft (I have a separate series of question on that draft). I'm >> saying the impersonation can work but ignoring the access tokens >> completely will make the overall solution much less flexible. >> I'd like to ask for some advice/guidance: >> - Is it a good idea at all for the client to use IdToken instead of >> AccessToken as explored above ? I suppose it can work, in the code flow >> the client gets the access token which, by default, only allows to >> access UserInfo. Perhaps the client impersonating IdToken for the >> purpose of accessing RS is not too bad after all. >> - Assuming the impersonation is OK, what is the right criteria for the >> client to choose to work with IdToken instead of the access token when >> accessing the immediate RS. It seems like if the impersonation is OK for >> the client to do then why have access tokens at all... >> - Assuming the impersonation is OK, does STS For the REST of Us shows >> the right and the only way it needs to be done ? I can imagine how it >> will work for the web app clients, but what about Implicit Clients. >> Many thanks, Sergey >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Aug 4 08:00:27 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A2612D541 for ; Thu, 4 Aug 2016 08:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 ZU3J5wORxQct for ; Thu, 4 Aug 2016 08:00:23 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1328012DA7D for ; Thu, 4 Aug 2016 08:00:23 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id f65so487180830wmi.0 for ; Thu, 04 Aug 2016 08:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Rkoov8zI2slhuUJdPHlcVNTaafkZ4wiQamuGZA5Ukdw=; b=bgZpp0W+8w6ZprdjYH003qNuvRMPPjUEqcqXIZGMQQ6p9ygmd3z13VmBbnqTHWxDUp DaiTlT2SaMNdnaalNc/klu7WeaP4tZPzOljKcSwYAmgklIUpGR3bzmvizPsqu+aogjsh 50brL8xu3Xbwj59RVBz5iQhCJQK37tPosGy6o9KvsHQVT+5pZCTuUknCWZIcr/vMwf0A DiGgLjBH8mYVY/XxZDizWPQR+HgDtBfJyyOrOFvEGouSeDCy6M3yWnK2tFVLNGO7CPzc mjX533wGJ2eteTrmkHzEaDosYm74XKTT7FsC1UgD+qe1vB/30yOxVe05TDq3krOMdyPv vv5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Rkoov8zI2slhuUJdPHlcVNTaafkZ4wiQamuGZA5Ukdw=; b=QzwLJe79vUdiWiEhQCwnLYdpBOz5mLCUYNu78lDIwKFRMsQpdPdXikpS70JYLGtbRz +mXazrlzhEB6w1MJt8QrnJbTfNQoX76Xi/Qp7MOQfFiwkd3lDVMAxcDAHc0FWsG47fdC YBXnNnDZUWfAUf6uExq+ggGXGcU+FsU3uZaI0wHrO76i26LH2TxxC23iRVl99RFbhc87 ooj4uOjfpmkI5hfE+R73epHfEjoyqFoa4RTHLIh/WDUS3YDtdN8AXfCDVVevXlV/eYOb rVQfBh0HcfMDqWdrH761Tx4fUko2Z6gEkiUFXXkDG+3aVrj1LGA9oMZtzPuLXdgYd9x3 5Kmw== X-Gm-Message-State: AEkoout2YWtJhAzzEGTxYz2ArBkKN1BqKP5EQ6QwITdNxrdQrJThoOJc9DJ1F3vyqTHoyQ== X-Received: by 10.194.78.74 with SMTP id z10mr74221646wjw.68.1470322821433; Thu, 04 Aug 2016 08:00:21 -0700 (PDT) Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id a9sm13275178wjf.16.2016.08.04.08.00.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Aug 2016 08:00:20 -0700 (PDT) To: Mike Schwartz References: From: Sergey Beryozkin Message-ID: <22f7eca5-d06f-a1ab-02a2-8f158f201b80@gmail.com> Date: Thu, 4 Aug 2016 16:00:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 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" Subject: Re: [OAUTH-WG] Using IdToken instead of Access token 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, 04 Aug 2016 15:00:26 -0000 Hi Mike On 04/08/16 14:00, Mike Schwartz wrote: > Sergey, > > Since no one answered your question, let me pose a few questions to your > questions! > > Wouldn't it give you more flexibility to issue a different token to > represent access to the RS API? If you refer to the fact that in the code flow the client gets both AccessToken and IdToken with the former to be used to access the RS API then indeed this is what I'm advocating. But I see in our internal discussions that the desire to use IdToken instead is strong and I'm finding I'm lacking some arguments to explain why using AT should be preferable and when the user impersonation by the client is acceptable then what is the right way to do it (I think it is the token exchange draft, the impersonation case). > In terms of passing user claims, > couldn't this be done via parameters in the API? No > Are you trying to do > more with OpenID Connect than was anticpiated in the design? This is what I'm saying that OIDC is primarily about the client authenticating the user and the access token returned as part of the OIDC code flow can be used by the client to continue working with the chained RSs on behalf of this user > The id_token has an audience, are you including more than one client in > that > audience? Would it make sense to look at token exchange and downscope > the token? Yes, I suppose this is what we should do > If you are looking for a profile of OAuth2, might UMA work? Haven't thought about it yet > > I think you're not alone in wondering what the answer to all these > questions are.. Thanks, Sergey > > - Mike > > > ------------------------------------- > Michael Schwartz > Gluu > http://gluu.org > >> Message: 3 >> Date: Wed, 3 Aug 2016 11:08:29 +0100 >> From: Sergey Beryozkin >> To: "oauth@ietf.org" >> Subject: [OAUTH-WG] Using IdToken instead of Access token >> Message-ID: >> Content-Type: text/plain; charset=windows-1252; format=flowed >> >> Hi All >> >> I hope this question is better suited for this list. Will have no >> problems redirecting it to the openid-connect list instead. >> >> Consider a user working with the client web application (OIDC RP) which >> authenticates the user with the OIDC authorization code flow at the end >> of which the client gets AccessToken + IdToken. Next the user requests >> something from the client which needs to access the RS to complete this >> request. >> >> And the idea is to have the client pass IdToken to RS and use various >> user claims inside this IdToken to enforce the access control at the RS >> level. My position it is likely wrong but I guess I may be missing >> something that will be either in favor or against it. >> >> The reason I think it is wrong is that if the client is using a code >> flow then the right approach for staying within the OAuth2 'world' is to >> use the access token to talk to RS and use IdToken only for the purpose >> of interacting with the user. The access token represents a proper user >> authorization and can have the extra scopes in addition to "oidc" which >> RS can depend upon in its access control restrictions. >> >> Next I'm arguing that if the IdToken is used instead then it is the case >> of the client impersonating the user. And refer to the STS for the REST >> of Us draft (I have a separate series of question on that draft). I'm >> saying the impersonation can work but ignoring the access tokens >> completely will make the overall solution much less flexible. >> >> I'd like to ask for some advice/guidance: >> >> - Is it a good idea at all for the client to use IdToken instead of >> AccessToken as explored above ? I suppose it can work, in the code flow >> the client gets the access token which, by default, only allows to >> access UserInfo. Perhaps the client impersonating IdToken for the >> purpose of accessing RS is not too bad after all. >> >> - Assuming the impersonation is OK, what is the right criteria for the >> client to choose to work with IdToken instead of the access token when >> accessing the immediate RS. It seems like if the impersonation is OK for >> the client to do then why have access tokens at all... >> >> - Assuming the impersonation is OK, does STS For the REST of Us shows >> the right and the only way it needs to be done ? I can imagine how it >> will work for the web app clients, but what about Implicit Clients. >> >> Many thanks, Sergey >> >> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Aug 4 08:17:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8047F12D18E for ; Thu, 4 Aug 2016 08:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 YReGoefzscE2 for ; Thu, 4 Aug 2016 08:17:40 -0700 (PDT) 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 B26A012D0A5 for ; Thu, 4 Aug 2016 08:17:39 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id x83so45455977wma.3 for ; Thu, 04 Aug 2016 08:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=ORD7CwQL3CrNaG+3OMv5D5zwmDfT7vXB4c2qHJxCMPo=; b=kh/tlUb0sEVrVcWz/1F7kKc7jzan1ymvzgmGsqpcnXE8UQ2UESSrp/TELKHfBm6io7 bAQ0urOOgyZKR57IH31ejA3FYakaReNJf+1jO7j7ckDHrdiOm1OUTDTabThsQngJUlBP AS7J2csSxdxow8Apx0g/4S52fKEx3YBOc+PIiBz7LTo/609LylCU1/wjFxaocuGeZFxq UXzejRANGRbf3Pt1XZ5HFs9kqPF9wXfXAxM2alpxePDcwH2ttEY4v66bULURtQoLop/o ME7Tns8LSGh7zQqqKYLSQgqP19AUZvgd7W9ry1fqnSGcqLM0YNLyDWHEsGWD9VJyW+fS /PcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ORD7CwQL3CrNaG+3OMv5D5zwmDfT7vXB4c2qHJxCMPo=; b=cRWxnfbJCk2SqGi7Q9sLqLf8gOpz9Nz9JMrFUxm24tdk3T6XYlBWoPW4AOHaSKtUu5 m0uUdnVYnwiyGjV99rTlkelBTnUn6+Cbt/Q4g2K0+Q2XRxDI7ZJsZuiHxZJKrf1Dtujl SgTo3HgZ035hAMFy+ygJlcYmpM3WE/hyF02q0OMtskEQXZFL8a4sflpyJXtok47ZaM3/ D/oOHshcJZCNA0QkiZEBbrPjBY5rFABtkxNbLmRXuAshCobKz1WSO1GNGUlVsMX4T6Ue LwXP2Vgoy0UiCcps2naLDWmpA8PU9Xw1ehEidrP8xKS+NESG1jygsRvpqXEZqSdVQ95G Q4Tg== X-Gm-Message-State: AEkooutS//zGzK3TyQf+n7FTfHVfgqTEJiMyfg0Xz+3eF+feFzDRqCVyo4GDePrzc0G0YQ== X-Received: by 10.28.150.146 with SMTP id y140mr31094834wmd.32.1470323857795; Thu, 04 Aug 2016 08:17:37 -0700 (PDT) Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id kq2sm13307794wjc.41.2016.08.04.08.17.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Aug 2016 08:17:37 -0700 (PDT) To: oauth@ietf.org References: <8F94CB33-41A6-438E-BE15-38A90FE653F5@oracle.com> From: Sergey Beryozkin Message-ID: <6a1e6f1e-16a3-c150-e057-a28a7d5b2b33@gmail.com> Date: Thu, 4 Aug 2016 16:17:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <8F94CB33-41A6-438E-BE15-38A90FE653F5@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Using IdToken instead of Access token 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, 04 Aug 2016 15:17:42 -0000 Hi Phil On 04/08/16 15:01, Phil Hunt (IDM) wrote: > You might be munging two different flows with different semantics together. > > First flow is use oidc to authen the user to the client. > > Second flow is normal oauth authorization to get an at to access the resource. > > Often the OP AS is different from the RS's AS and the rs needs a proper "delegation" access token. Indeed, this is more or less what I've been saying in our private discussions. But as I said to in my response to Mike, I see a demand to have IdToken propagated and given the token exchange draft has a dedicated 'impersonation' section I'm assuming there's a need for it. For example, I was checking the archives, could see Brian Campbell quoting Vittorio Bertocci: "To summarize our main use case: we use [a token exchange like protocol] for achieving user impersonation thru tiers, or delegation for confidential clients which do not have any web UX..." The former case there suggests that if a client has a web UI they authenticate the user first and then start impersonating. I'm advocating for the clients to use the access tokens. The clients can requests the extra scopes while authenticating the user and if the user approves these scopes the client can continue using AT on behalf of the client, and using IdToken to only interact with the user. But I'm finding it difficult to explain (show a clear differentiator) when the client should use AT and when they should use IdToken to impersonate a user and get a new token (via the token exchange)... Sergey > > Phil > >> On Aug 4, 2016, at 6:00 AM, Mike Schwartz wrote: >> >> Sergey, >> >> Since no one answered your question, let me pose a few questions to your questions! >> >> Wouldn't it give you more flexibility to issue a different token to >> represent access to the RS API? In terms of passing user claims, >> couldn't this be done via parameters in the API? Are you trying to do >> more with OpenID Connect than was anticpiated in the design? >> The id_token has an audience, are you including more than one client in that >> audience? Would it make sense to look at token exchange and downscope the token? >> If you are looking for a profile of OAuth2, might UMA work? >> >> I think you're not alone in wondering what the answer to all these questions are.. >> >> - Mike >> >> >> ------------------------------------- >> Michael Schwartz >> Gluu >> http://gluu.org >> >>> Message: 3 >>> Date: Wed, 3 Aug 2016 11:08:29 +0100 >>> From: Sergey Beryozkin >>> To: "oauth@ietf.org" >>> Subject: [OAUTH-WG] Using IdToken instead of Access token >>> Message-ID: >>> Content-Type: text/plain; charset=windows-1252; format=flowed >>> Hi All >>> I hope this question is better suited for this list. Will have no >>> problems redirecting it to the openid-connect list instead. >>> Consider a user working with the client web application (OIDC RP) which >>> authenticates the user with the OIDC authorization code flow at the end >>> of which the client gets AccessToken + IdToken. Next the user requests >>> something from the client which needs to access the RS to complete this >>> request. >>> And the idea is to have the client pass IdToken to RS and use various >>> user claims inside this IdToken to enforce the access control at the RS >>> level. My position it is likely wrong but I guess I may be missing >>> something that will be either in favor or against it. >>> The reason I think it is wrong is that if the client is using a code >>> flow then the right approach for staying within the OAuth2 'world' is to >>> use the access token to talk to RS and use IdToken only for the purpose >>> of interacting with the user. The access token represents a proper user >>> authorization and can have the extra scopes in addition to "oidc" which >>> RS can depend upon in its access control restrictions. >>> Next I'm arguing that if the IdToken is used instead then it is the case >>> of the client impersonating the user. And refer to the STS for the REST >>> of Us draft (I have a separate series of question on that draft). I'm >>> saying the impersonation can work but ignoring the access tokens >>> completely will make the overall solution much less flexible. >>> I'd like to ask for some advice/guidance: >>> - Is it a good idea at all for the client to use IdToken instead of >>> AccessToken as explored above ? I suppose it can work, in the code flow >>> the client gets the access token which, by default, only allows to >>> access UserInfo. Perhaps the client impersonating IdToken for the >>> purpose of accessing RS is not too bad after all. >>> - Assuming the impersonation is OK, what is the right criteria for the >>> client to choose to work with IdToken instead of the access token when >>> accessing the immediate RS. It seems like if the impersonation is OK for >>> the client to do then why have access tokens at all... >>> - Assuming the impersonation is OK, does STS For the REST of Us shows >>> the right and the only way it needs to be done ? I can imagine how it >>> will work for the web app clients, but what about Implicit Clients. >>> Many thanks, Sergey >> >> _______________________________________________ >> 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 > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ From nobody Thu Aug 4 08:37:15 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D13012D7F7 for ; Thu, 4 Aug 2016 08:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=herberg.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayloLpUsX9vd for ; Thu, 4 Aug 2016 08:37:11 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613E4127058 for ; Thu, 4 Aug 2016 08:37:11 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id m101so273987511ioi.2 for ; Thu, 04 Aug 2016 08:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Re0mpibN/YQGy/b+ws4SBM1J4kikHA+YdcUsJXnT4M8=; b=oCvnU1vjy49pNTATVnGYI4pidUv4zxsFe/ydMIJrEUsQ3pKZSPO61YyJSLw6J7oPBm P6kMfBrz85IB37ky2ZavYOH1YY0U1llJCI/qlmVGdV7PVZyesloSE1+rxvmL9fdnaEnI /18L9xWzwQOZaBmzK+IU84ggNc5+Skg9LBAck= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Re0mpibN/YQGy/b+ws4SBM1J4kikHA+YdcUsJXnT4M8=; b=ePj5PPu/RazMJMDn0VR8dOki2H4xuZZUNsMzBSOKPbB6zHfPqUOClkKapHW4BMCywG 9ZKoy5szwLa7jbd1v9UChohu8yqubTl4Fr7uHSYtT7wBHY/+n1iZX9X7+6MNaE/K1VhA 1P4bxcEl0Z7R9Poid0hzNRLihMvJ8EyRhF62Cdf4l2nr8Q7FrPiTlayPHiKf5MbOxGr4 782jQhrzEtrcw02L9kGizdCaxaUyI6dXUmHssU6EYnVFhrKNNLUARPJKFiIKWOJsMQiL rdhJpHpo1tpjZlgcjR9XfqX55hEjZxwLWXYPmQBPBavqVBMf4+xzFlD+V2RdtC2Q5Lb0 TSxg== X-Gm-Message-State: AEkoousgDXX4iZ1F8fpVg1n+DrH/zVTB3nYAScrb8X8E/CmVUKnz7nxCctC4EjZeTet7jQuGdngi9ICod3Zqqw== X-Received: by 10.107.165.146 with SMTP id o140mr71529527ioe.151.1470325030526; Thu, 04 Aug 2016 08:37:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.23.88 with HTTP; Thu, 4 Aug 2016 08:37:10 -0700 (PDT) In-Reply-To: References: From: Ulrich Herberg Date: Thu, 4 Aug 2016 08:37:10 -0700 Message-ID: To: John Bradley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [OAUTH-WG] draft-ietf-oauth-native-apps-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: Thu, 04 Aug 2016 15:37:13 -0000 Thanks, John. Do you think that for the last two of my points it would be useful to add some informative text to the draft, similar to the answer you provided in your email? Regards Ulrich On Wed, Aug 3, 2016 at 3:22 PM, John Bradley wrote: > Sorry I missed your comments. > > Inline >> On Apr 4, 2016, at 1:09 PM, Ulrich Herberg wrote: >> >> Hi, >> >> I have read draft-ietf-oauth-native-apps-01 and I generally agree with >> the overall recommendations in the draft, and it is well written (I >> haven't participated in this WG before, so I don't know what to what >> level it has already been discussed). >> >> Some comments: >> - Section 2, last paragraph: >> I agree with the general recommendation to not use an external user >> agent because of complexity. However, there are cases when a tablet is >> sold as a closed system and under full control of the vendor. In these >> cases, the vendor can preinstall the AS user agent into the operating >> system and provide APIs for other apps to use it. >> > Yes that is possable but this document is not describing how to use such = an external token agent. > That needs to be a separate spec. We did start one called NAPPS in the O= penID foundation but have largely abandoned it due to to the complexity of = also needing to change OAuth to support that model. > > It can be done but so far only in a relatively closed environment. For a= pplications that need to work with multiple authentication servers the mode= l of doing OAuth via a system browser seems the most strait-forward. > > We are recommending not doing it and saying if you want to it is out of s= cope. If you have some specific text you would like to see let us know. > >> >> - Section 5.1 (Embedded User-agents): "Authorization servers SHOULD >> consider taking steps to detect and block logins via embedded >> user-agents that are not their own, where possible." >> >> Do you have any recommendation how to do that, other than reading the >> (easily modifiable) User-Agent HTTP header? Maybe you could add a >> sentence for providing some guidance here. > > At the moment looking at the browser strings and blacklisting client id o= f apps that fake them is the only thing we have at the moment. > > I think Google is currently looking into this and William may have more i= nformation. >> >> >> - Section 5.3 (Phishing): >> This is indeed concerning; it's very easy to fake the in-app browser. >> The draft says: "If all native apps use the techniques described in >> this best practice, users will not need to sign-in frequently and thus >> should be suspicious of any sign-in request when they should have >> already been signed-in." >> >> That is true, in theory, but sounds like a big "if" to me. Most users >> are not savvy enough to be suspicious if a login screen appears and it >> looks the same as the one they know. >> I admit that I don't have any suggestion how to do it better, but this >> part seems to be the most problematic to me for using OAuth on native >> devices. > > I don=E2=80=99t think we have any magic bullet for fake apps. > There are some techniques to cookie the browser with the users photo or o= ther information that will be harder to fake outside the real browser. > Un-phishable credentials like Fido may be the only long term answer for t= his, but at least this recommendation of using the system or external brows= er make using Fido possable where U2F atleast is blocked from webviews curr= ently. > > John B. >> >> Best regards >> Ulrich >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Thu Aug 4 08:38:00 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483D012D8B8 for ; Thu, 4 Aug 2016 08:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=herberg.name Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KhoHgSb3UjZ for ; Thu, 4 Aug 2016 08:37:54 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C60127058 for ; Thu, 4 Aug 2016 08:37:53 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id q83so274866304iod.1 for ; Thu, 04 Aug 2016 08:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M+Yg35ljtXRJeYfgQq7Ds+w1dpl8xaFzEksQZFz8OTw=; b=UpYMaNr92lliEhkmhBZPUzLT0FdXqHD6ilJu0uEag03eNTLObGyi8bad2/EtWs5QCo Fhm7dmSAvrYDwwY7UhthhcA7qjYBUNc/74mtgwT8eh7YwwNa2zq4jaut1mmEmtcZB42P KDy6racgHY4PfJwxFfN+lpFfubCuz4nLkgNmQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M+Yg35ljtXRJeYfgQq7Ds+w1dpl8xaFzEksQZFz8OTw=; b=Mq1VWGhqKEtGH/uvjdOU5LIbHbBrzB9N5+2iJvuk6GiFDNymNy9E1CasmTSiBuroUt LPTSpMKoYrTLloLN6qlZuvNbROKgVkr5djbsqnegyiwFvAJJyzqVdehHrQo5mUS8X2gm nQ/GIBItZXBx81uxlKsOFqOAFKaxdMIgrtjO8o7qidci4jgEcmYd4PBOHIGKXVquCsza pytbeesG5guEPmgLEqzm7lnU9M9GKCj6xCrA1v6gWMbNePyHYz0HyooG/guv/CXimeFY w4W90QBTIF2PhgWAlJHDCzb2TvUrfi28Nc+nuEi9cNtK6TI4QTZKH1peQ3vapzKc6SI5 Zjbw== X-Gm-Message-State: AEkoouuubTCjohNXHl7FcpL2ebzOQFYpyeTjil1XouiCOG5CIKuKsS6n4andCWPyllZtPPQXmrn1A49YKi9Z1g== X-Received: by 10.107.3.35 with SMTP id 35mr74361348iod.40.1470325072919; Thu, 04 Aug 2016 08:37:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.23.88 with HTTP; Thu, 4 Aug 2016 08:37:52 -0700 (PDT) In-Reply-To: <1A386E9C-D198-495C-B1F2-B8A986915FEA@ve7jtb.com> References: <1A386E9C-D198-495C-B1F2-B8A986915FEA@ve7jtb.com> From: Ulrich Herberg Date: Thu, 4 Aug 2016 08:37:52 -0700 Message-ID: To: John Bradley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] draft-ietf-oauth-native-apps-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: Thu, 04 Aug 2016 15:37:57 -0000 Sounds interesting! Thanks Ulrich On Wed, Aug 3, 2016 at 3:30 PM, John Bradley wrote: > Inline > >> On Apr 15, 2016, at 1:10 AM, Ulrich Herberg wrote: >> >> Hi, >> >> I was wondering if you had any thoughts about my comments below from >> my other email? >> >> In addition, I was wondering about the case where the client ID and >> client secret of an app has been leaked. The draft mentions the case >> where a rogue app intercepts the auth code by using the same redirect >> URL scheme of another app and how to mitigate that with PKCE. >> But how could you prevent the rogue app from pretending to be another >> app in case it got hold of the Client ID and Client Secret of that >> app? In that case, couldn't it initiate the auth request (and thereby >> pass the PKCE verification correctly)? >> > This spec is not intended to stop app impersonation. > PKCE os no help with this. > > William and I are also working on an attestation spec that will allow the OS to attest to an applications developer key and bundle ID. > To do that securely we want to use token binding to bind the attestation to the app making the call to a token endpoint. > > It is different enough, and has a number of dependencies on new work that we did not want to block getting these best practices out, on new work. > > I agree that app impersonation will become a real problem, but one step at a time. > > John B. > > >> Thanks >> Ulrich >> >> On Mon, Apr 4, 2016 at 10:09 AM, Ulrich Herberg wrote: >>> Hi, >>> >>> I have read draft-ietf-oauth-native-apps-01 and I generally agree with >>> the overall recommendations in the draft, and it is well written (I >>> haven't participated in this WG before, so I don't know what to what >>> level it has already been discussed). >>> >>> Some comments: >>> - Section 2, last paragraph: >>> I agree with the general recommendation to not use an external user >>> agent because of complexity. However, there are cases when a tablet is >>> sold as a closed system and under full control of the vendor. In these >>> cases, the vendor can preinstall the AS user agent into the operating >>> system and provide APIs for other apps to use it. >>> >>> >>> - Section 5.1 (Embedded User-agents): "Authorization servers SHOULD >>> consider taking steps to detect and block logins via embedded >>> user-agents that are not their own, where possible." >>> >>> Do you have any recommendation how to do that, other than reading the >>> (easily modifiable) User-Agent HTTP header? Maybe you could add a >>> sentence for providing some guidance here. >>> >>> >>> - Section 5.3 (Phishing): >>> This is indeed concerning; it's very easy to fake the in-app browser. >>> The draft says: "If all native apps use the techniques described in >>> this best practice, users will not need to sign-in frequently and thus >>> should be suspicious of any sign-in request when they should have >>> already been signed-in." >>> >>> That is true, in theory, but sounds like a big "if" to me. Most users >>> are not savvy enough to be suspicious if a login screen appears and it >>> looks the same as the one they know. >>> I admit that I don't have any suggestion how to do it better, but this >>> part seems to be the most problematic to me for using OAuth on native >>> devices. >>> >>> Best regards >>> Ulrich >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Thu Aug 4 08:48:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8685412D0C8 for ; Thu, 4 Aug 2016 08:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 6J7F4bF6AHGi for ; Thu, 4 Aug 2016 08:48:29 -0700 (PDT) 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 3F82012D0A0 for ; Thu, 4 Aug 2016 08:48:29 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u74FmRVo019734 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2016 15:48:27 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u74FmRB5006860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Aug 2016 15:48:27 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u74FmQkC028739; Thu, 4 Aug 2016 15:48:26 GMT Received: from [25.56.8.220] (/24.114.80.140) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 04 Aug 2016 08:48:25 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13G34) In-Reply-To: <6a1e6f1e-16a3-c150-e057-a28a7d5b2b33@gmail.com> Date: Thu, 4 Aug 2016 08:48:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <92C34C25-4153-4529-9E2C-10EA4E5ED894@oracle.com> References: <8F94CB33-41A6-438E-BE15-38A90FE653F5@oracle.com> <6a1e6f1e-16a3-c150-e057-a28a7d5b2b33@gmail.com> To: Sergey Beryozkin X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Using IdToken instead of Access token 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, 04 Aug 2016 15:48:31 -0000 This is as bad as assuming an access token means someone was authenticated.=20= In this case the audience of the id token is not the resource and other badn= ess may ensue.=20 Phil > On Aug 4, 2016, at 8:17 AM, Sergey Beryozkin wrote:= >=20 > Hi Phil >=20 >> On 04/08/16 15:01, Phil Hunt (IDM) wrote: >> You might be munging two different flows with different semantics togethe= r. >>=20 >> First flow is use oidc to authen the user to the client. >>=20 >> Second flow is normal oauth authorization to get an at to access the reso= urce. >>=20 >> Often the OP AS is different from the RS's AS and the rs needs a proper "= delegation" access token. > Indeed, this is more or less what I've been saying in our private discussi= ons. >=20 > But as I said to in my response to Mike, I see a demand to have IdToken pr= opagated and given the token exchange draft has a dedicated 'impersonation' s= ection I'm assuming there's a need for it. >=20 > For example, I was checking the archives, could see Brian Campbell quoting= Vittorio Bertocci: > "To summarize our main use case: we use [a token exchange like protocol] f= or achieving user impersonation thru tiers, or delegation for confidential c= lients which do not have any web UX..." >=20 > The former case there suggests that if a client has a web UI they authenti= cate the user first and then start impersonating. >=20 > I'm advocating for the clients to use the access tokens. The clients can r= equests the extra scopes while authenticating the user and if the user appro= ves these scopes the client can continue using AT on behalf of the client, a= nd using IdToken to only interact with the user. >=20 > But I'm finding it difficult to explain (show a clear differentiator) when= the client should use AT and when they should use IdToken to impersonate a u= ser and get a new token (via the token exchange)... >=20 > Sergey >>=20 >> Phil >>=20 >>> On Aug 4, 2016, at 6:00 AM, Mike Schwartz wrote: >>>=20 >>> Sergey, >>>=20 >>> Since no one answered your question, let me pose a few questions to your= questions! >>>=20 >>> Wouldn't it give you more flexibility to issue a different token to >>> represent access to the RS API? In terms of passing user claims, >>> couldn't this be done via parameters in the API? Are you trying to do >>> more with OpenID Connect than was anticpiated in the design? >>> The id_token has an audience, are you including more than one client in t= hat >>> audience? Would it make sense to look at token exchange and downscope th= e token? >>> If you are looking for a profile of OAuth2, might UMA work? >>>=20 >>> I think you're not alone in wondering what the answer to all these quest= ions are.. >>>=20 >>> - Mike >>>=20 >>>=20 >>> ------------------------------------- >>> Michael Schwartz >>> Gluu >>> http://gluu.org >>>=20 >>>> Message: 3 >>>> Date: Wed, 3 Aug 2016 11:08:29 +0100 >>>> From: Sergey Beryozkin >>>> To: "oauth@ietf.org" >>>> Subject: [OAUTH-WG] Using IdToken instead of Access token >>>> Message-ID: >>>> Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed >>>> Hi All >>>> I hope this question is better suited for this list. Will have no >>>> problems redirecting it to the openid-connect list instead. >>>> Consider a user working with the client web application (OIDC RP) which= >>>> authenticates the user with the OIDC authorization code flow at the end= >>>> of which the client gets AccessToken + IdToken. Next the user requests >>>> something from the client which needs to access the RS to complete this= >>>> request. >>>> And the idea is to have the client pass IdToken to RS and use various >>>> user claims inside this IdToken to enforce the access control at the RS= >>>> level. My position it is likely wrong but I guess I may be missing >>>> something that will be either in favor or against it. >>>> The reason I think it is wrong is that if the client is using a code >>>> flow then the right approach for staying within the OAuth2 'world' is t= o >>>> use the access token to talk to RS and use IdToken only for the purpose= >>>> of interacting with the user. The access token represents a proper user= >>>> authorization and can have the extra scopes in addition to "oidc" which= >>>> RS can depend upon in its access control restrictions. >>>> Next I'm arguing that if the IdToken is used instead then it is the cas= e >>>> of the client impersonating the user. And refer to the STS for the REST= >>>> of Us draft (I have a separate series of question on that draft). I'm >>>> saying the impersonation can work but ignoring the access tokens >>>> completely will make the overall solution much less flexible. >>>> I'd like to ask for some advice/guidance: >>>> - Is it a good idea at all for the client to use IdToken instead of >>>> AccessToken as explored above ? I suppose it can work, in the code flow= >>>> the client gets the access token which, by default, only allows to >>>> access UserInfo. Perhaps the client impersonating IdToken for the >>>> purpose of accessing RS is not too bad after all. >>>> - Assuming the impersonation is OK, what is the right criteria for the >>>> client to choose to work with IdToken instead of the access token when >>>> accessing the immediate RS. It seems like if the impersonation is OK fo= r >>>> the client to do then why have access tokens at all... >>>> - Assuming the impersonation is OK, does STS For the REST of Us shows >>>> the right and the only way it needs to be done ? I can imagine how it >>>> will work for the web app clients, but what about Implicit Clients. >>>> Many thanks, Sergey >>>=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 >=20 > --=20 > Sergey Beryozkin >=20 > Talend Community Coders > http://coders.talend.com/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Aug 4 09:04:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BF212D1DE for ; Thu, 4 Aug 2016 09:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgZ8vVUWojgk for ; Thu, 4 Aug 2016 09:04:37 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 BA09A12B007 for ; Thu, 4 Aug 2016 09:04:37 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id p186so109143734qkd.1 for ; Thu, 04 Aug 2016 09:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GB8YA/feV/MizW+epcd0Zattw/LmBk/DnJ426Tvm8vU=; b=eS8ZWk9tjS0I6tu1Xr2T9K/qyN0ygz9FY4NRzdW1f5g4sup/qGGPyyrRqqcmb73Jmo 5ICijmOgEbsxbezThiquaalJDuh6MXTSU4ZNzR3tP9MzVyAkSadcn7aX22Es8VsWJfMM VWg6DO8CbZIMwZ/+XmpZ7YvNuz9QBtDk9uiDJ2aesH9bVABmymf4lvkvi/qNeV1eaANO atqaH5S78mAzgPkjKlsimURnMLLfpKCDx0UnQd0nioofKAr1OgP6nopCJyRJxDf2PDeK cLmIeq7Fq1RRsRX0uFfEHBX4jiePepkC81ycEBIh/ild5ZSuGD9uXV8U/8j/9kZyymEk 17eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GB8YA/feV/MizW+epcd0Zattw/LmBk/DnJ426Tvm8vU=; b=N/haWByrvrEMXvY5QWOJs3I/A0EjEuPJ9XlkNYUMgdfLs9X5vYpd2skZ53Ztb2IyAJ 5UfRARgD/tVDbIKr2RCGtAipltBDuZBHAwmUU+m26rKN+7LRPXjyy1YsYmFl43KMylzC /kdw5oQUBhonJLuH+ixaDX8W80iu/u7nyVMKktA3i3ENIBUc+/Jza2DwTjvJdSP8WNis K0cNwuauFGTh0o8NfiGd8x1y6IL2FfLJmMxyC10BD8Qy2/B10e79WFK/gB65eva85wyj 0BRKGi6v/R+QvHnO1jM+9X67l8C5XQQSeyTUMVFDDut3K78OgmxSeiHUy//lSzRhjjdp /HUw== X-Gm-Message-State: AEkoouu56l6ZRgH2+0jkSPqltzLOBj5YBL+aB1FEFgOq+GMyatW+aX0sQ8DxIy8yD4jcsSS6 X-Received: by 10.55.119.69 with SMTP id s66mr6977582qkc.48.1470326676669; Thu, 04 Aug 2016 09:04:36 -0700 (PDT) Received: from [192.168.1.49] ([191.115.63.14]) by smtp.gmail.com with ESMTPSA id s52sm7276811qtc.4.2016.08.04.09.04.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Aug 2016 09:04:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <6a1e6f1e-16a3-c150-e057-a28a7d5b2b33@gmail.com> Date: Thu, 4 Aug 2016 12:04:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5E317DFF-AE9B-4D18-9281-3C349AB57357@ve7jtb.com> References: <8F94CB33-41A6-438E-BE15-38A90FE653F5@oracle.com> <6a1e6f1e-16a3-c150-e057-a28a7d5b2b33@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.3124) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Using IdToken instead of Access token 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, 04 Aug 2016 16:04:40 -0000 The id_token and access token have different semantics, and quite = possable possibly formats. So the AT that comes with the id_token will be useful at RS associated = with the AS, but it may not be useful at other API the client wants to = access and that is generally where we run into the use case for token = exchange. In the case of talking to a third party API it may be useful to have = that API have a token exchange endpoint where a client can exchange a = id_token/JWT for an access token. =20 That is clearer and likely more secure given a confidential client than = just using the id_token as a access token directly. Now I do understand people do that now. In the hopefully near future once we have token binding as a proof of = possession mechanism it will be come clearer that you cant take a = id_token that is bound to the browser presenting the token to the client = and directly re use that as a secure access token. The AT and RT = issued with that token will be bound to the client so that the RS can = validate them. There are a lot of bad patterns possible with bearer tokens. I prefer = to try to avoid them so that people will be in a better position when we = move off bearer tokens for increased security. John B. > On Aug 4, 2016, at 11:17 AM, Sergey Beryozkin = wrote: >=20 > Hi Phil >=20 > On 04/08/16 15:01, Phil Hunt (IDM) wrote: >> You might be munging two different flows with different semantics = together. >>=20 >> First flow is use oidc to authen the user to the client. >>=20 >> Second flow is normal oauth authorization to get an at to access the = resource. >>=20 >> Often the OP AS is different from the RS's AS and the rs needs a = proper "delegation" access token. > Indeed, this is more or less what I've been saying in our private = discussions. >=20 > But as I said to in my response to Mike, I see a demand to have = IdToken propagated and given the token exchange draft has a dedicated = 'impersonation' section I'm assuming there's a need for it. >=20 > For example, I was checking the archives, could see Brian Campbell = quoting Vittorio Bertocci: > "To summarize our main use case: we use [a token exchange like = protocol] for achieving user impersonation thru tiers, or delegation for = confidential clients which do not have any web UX..." >=20 > The former case there suggests that if a client has a web UI they = authenticate the user first and then start impersonating. >=20 > I'm advocating for the clients to use the access tokens. The clients = can requests the extra scopes while authenticating the user and if the = user approves these scopes the client can continue using AT on behalf of = the client, and using IdToken to only interact with the user. >=20 > But I'm finding it difficult to explain (show a clear differentiator) = when the client should use AT and when they should use IdToken to = impersonate a user and get a new token (via the token exchange)... >=20 > Sergey >>=20 >> Phil >>=20 >>> On Aug 4, 2016, at 6:00 AM, Mike Schwartz wrote: >>>=20 >>> Sergey, >>>=20 >>> Since no one answered your question, let me pose a few questions to = your questions! >>>=20 >>> Wouldn't it give you more flexibility to issue a different token to >>> represent access to the RS API? In terms of passing user claims, >>> couldn't this be done via parameters in the API? Are you trying to = do >>> more with OpenID Connect than was anticpiated in the design? >>> The id_token has an audience, are you including more than one client = in that >>> audience? Would it make sense to look at token exchange and = downscope the token? >>> If you are looking for a profile of OAuth2, might UMA work? >>>=20 >>> I think you're not alone in wondering what the answer to all these = questions are.. >>>=20 >>> - Mike >>>=20 >>>=20 >>> ------------------------------------- >>> Michael Schwartz >>> Gluu >>> http://gluu.org >>>=20 >>>> Message: 3 >>>> Date: Wed, 3 Aug 2016 11:08:29 +0100 >>>> From: Sergey Beryozkin >>>> To: "oauth@ietf.org" >>>> Subject: [OAUTH-WG] Using IdToken instead of Access token >>>> Message-ID: >>>> Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed >>>> Hi All >>>> I hope this question is better suited for this list. Will have no >>>> problems redirecting it to the openid-connect list instead. >>>> Consider a user working with the client web application (OIDC RP) = which >>>> authenticates the user with the OIDC authorization code flow at the = end >>>> of which the client gets AccessToken + IdToken. Next the user = requests >>>> something from the client which needs to access the RS to complete = this >>>> request. >>>> And the idea is to have the client pass IdToken to RS and use = various >>>> user claims inside this IdToken to enforce the access control at = the RS >>>> level. My position it is likely wrong but I guess I may be missing >>>> something that will be either in favor or against it. >>>> The reason I think it is wrong is that if the client is using a = code >>>> flow then the right approach for staying within the OAuth2 'world' = is to >>>> use the access token to talk to RS and use IdToken only for the = purpose >>>> of interacting with the user. The access token represents a proper = user >>>> authorization and can have the extra scopes in addition to "oidc" = which >>>> RS can depend upon in its access control restrictions. >>>> Next I'm arguing that if the IdToken is used instead then it is the = case >>>> of the client impersonating the user. And refer to the STS for the = REST >>>> of Us draft (I have a separate series of question on that draft). = I'm >>>> saying the impersonation can work but ignoring the access tokens >>>> completely will make the overall solution much less flexible. >>>> I'd like to ask for some advice/guidance: >>>> - Is it a good idea at all for the client to use IdToken instead of >>>> AccessToken as explored above ? I suppose it can work, in the code = flow >>>> the client gets the access token which, by default, only allows to >>>> access UserInfo. Perhaps the client impersonating IdToken for the >>>> purpose of accessing RS is not too bad after all. >>>> - Assuming the impersonation is OK, what is the right criteria for = the >>>> client to choose to work with IdToken instead of the access token = when >>>> accessing the immediate RS. It seems like if the impersonation is = OK for >>>> the client to do then why have access tokens at all... >>>> - Assuming the impersonation is OK, does STS For the REST of Us = shows >>>> the right and the only way it needs to be done ? I can imagine how = it >>>> will work for the web app clients, but what about Implicit Clients. >>>> Many thanks, Sergey >>>=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 >=20 >=20 > --=20 > Sergey Beryozkin >=20 > Talend Community Coders > http://coders.talend.com/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Thu Aug 4 09:11:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1A312D63E for ; Thu, 4 Aug 2016 09:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb6NEDL35EJj for ; Thu, 4 Aug 2016 09:11:22 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E0612B007 for ; Thu, 4 Aug 2016 09:11:20 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id 38so275230523iol.0 for ; Thu, 04 Aug 2016 09:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0lxGT0qEvKKSCT4TW/t3cAga4dA+nZvgf/s6zohioz8=; b=C48wlST4CmMMUbRoaN99TfhOE+gi5dCe5JT3/1bg7ixKqJq6Bxa3S0H0AgWl2NiM55 1nsruUL+btIO39bJNQOnYzVoUMd7faENxN5xlns+wC9jyzTJpdg6iBw1p5JjPNxBZSxZ +ox02P+gyEDC9Z5QbzEv05mx+TVUv4WvaaC0E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0lxGT0qEvKKSCT4TW/t3cAga4dA+nZvgf/s6zohioz8=; b=EVRzD0Ystwiz6BmhQpk6+GbpUBcRJMBocRDVvfGUTFxJoDFW+1GlZCZx/5tc6Tx/vV 2uGK5jq7cJ+xp0+XX78iIQmJdKKJKfC1u0/v1l8nxkZnu9CkIAmPmtcf9qKJRlsDACeB /UlaeNmG9QHidN+kkWwzrVIychCLBmIQiXoi38PTr1WbNOqxMyLL4k9sgWt1dqVJGANP 01bdlC5ASa3AtU3D7NlVPhIbp7fZkH5ux0i6P2lY//zcFQmEJ0P1ZeQDFybRZ1q+clzz o6oGRQ3VvyS82a5bqfQKlDByhF7bPtGljDcP4qhbYG6JQ6PFSINYrogzjP0LpfyB1JXh rPzw== X-Gm-Message-State: AEkooutSI7BPeX4IRFu5dHUAUzzh56dMLdAMieJhfQWDZcjWkVKcPsINhpRzi4E6Nc7Hdz7UFDVd4z3slOWLvaIG X-Received: by 10.107.50.19 with SMTP id y19mr71400028ioy.174.1470327079711; Thu, 04 Aug 2016 09:11:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Thu, 4 Aug 2016 09:10:49 -0700 (PDT) In-Reply-To: <33052033-0992-ceb8-4390-6837017b140e@gmx.net> References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net> From: Brian Campbell Date: Thu, 4 Aug 2016 10:10:49 -0600 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a114469c44a556005394133a0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0 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, 04 Aug 2016 16:11:24 -0000 --001a114469c44a556005394133a0 Content-Type: text/plain; charset=UTF-8 I accept these documents as a starting point of the Token binding work in OAuth. With emphases on "starting point" because even the initial discussions about the work in Berlin uncovered changes that'll be necessary or desirable. On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig wrote: > Hi all, > > this is the call for adoption of the 'OAuth 2.0 Token Binding' document > bundle* following the positive call for adoption at the recent IETF > meeting in Berlin. > > Here are the links to the documents presented at the last IETF meeting: > https://tools.ietf.org/html/draft-jones-oauth-token-binding-00 > https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 > > Please let us know by August 17th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Ciao > Hannes & Derek > > *: We will find out what the best document structure is later, i.e., > whether the content should be included in one, two or multiple documents. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a114469c44a556005394133a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I accept these documents as a starting point of the T= oken binding work in OAuth.

With emphases on "starting p= oint" because even the initial discussions about the work in Berlin un= covered changes that'll be necessary or desirable.=C2=A0

On Wed, Aug 3, 2016 a= t 1:45 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

this is the call for adoption of the 'OAuth 2.0 Token Binding' docu= ment
bundle* following the positive call for adoption at the recent IETF
meeting in Berlin.

Here are the links to the documents presented at the last IETF meeting:
https://tools.ietf.org/html/draft-jone= s-oauth-token-binding-00
https://tools.ietf.org/html/draft-campbel= l-oauth-tbpkce-00

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

Ciao
Hannes & Derek

*: We will find out what the best document structure is later, i.e.,
whether the content should be included in one, two or multiple documents.

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


--001a114469c44a556005394133a0-- From nobody Thu Aug 4 09:23:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06EB12B078 for ; Thu, 4 Aug 2016 09:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 wF2vO8epmNmH for ; Thu, 4 Aug 2016 09:23:05 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BAB12D67E for ; Thu, 4 Aug 2016 09:23:04 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id i5so51535wmg.0 for ; Thu, 04 Aug 2016 09:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=OWwxC68VXfoMtiAfy2qfgQaJDDRsRMjfRXbhz5f/xek=; b=j1UzpQFjWI21dIGS3bYGArc5DSSFWvwi45ceP8kXYi/7MRgAUBPkoLVurdefPUDWhK XFbE6tXVhMYvWnxIpZTacXY1tcWEtL3rXWqjkmVGVA72z29s/mDetxRdiZSoQBpDErIN uase0q/USiipksUltkn9EMC8LsZS3NbEj3/Fij3ohPjMPH3L2SgIiYKn7V7Nkl3bEYCI e85LIH2RJzqUfdqbG202QnfEqiFxbK5WJuiQQ68FQPBnQqkGpWqYRzm1UI/pNDKFK6wU IfPnHj/I1X3EWdobe8WTcdaG8f0lPXqMDUjqoYIBl7BsHd7hx55S1rfViXkl4XfFqvCM 2qLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=OWwxC68VXfoMtiAfy2qfgQaJDDRsRMjfRXbhz5f/xek=; b=JDn6BRmwjBcfswStwqBHp+Ga177dXIHNPBaMLhz+LH9cKRZf9RaqqdA1Am4X4oJk+a nScZs4KsSBcH3QmFHRMGVRDl6Z+E66Sck1tmCzJjmsCPp6/TwqYZMQ9iCzMAmCPfxAOY AyumBnbFC6wR/oC3RVvZIaobHPElBbpC5VYp4S7zUMPCAQIyKwIywQdebz7Dr+AhFPfE 4GWPrQOtwAPzsIvL9l0iBLV/pJX1VsvG3mvzoFCskaPmOxZy2Z+5eFVDeWwPkU7x9AeT jbpMNmZ2I6dLNNJquNHycZF9iYWW+ye7VNUYBhep8vVL1zIFS70JxUjXa+8gR0t+Fg8L elIg== X-Gm-Message-State: AEkoouuYJ7pX0I502vFvu2+0jLL4sF+AQAA20nWsN4j7lFYEgrhH7pJpcOQsHeOWaDyMvg== X-Received: by 10.28.209.134 with SMTP id i128mr29455114wmg.97.1470327783051; Thu, 04 Aug 2016 09:23:03 -0700 (PDT) Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id u125sm4337904wmg.22.2016.08.04.09.23.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Aug 2016 09:23:02 -0700 (PDT) To: "Phil Hunt (IDM)" References: <8F94CB33-41A6-438E-BE15-38A90FE653F5@oracle.com> <6a1e6f1e-16a3-c150-e057-a28a7d5b2b33@gmail.com> <92C34C25-4153-4529-9E2C-10EA4E5ED894@oracle.com> From: Sergey Beryozkin Message-ID: Date: Thu, 4 Aug 2016 17:22:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <92C34C25-4153-4529-9E2C-10EA4E5ED894@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Using IdToken instead of Access token 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, 04 Aug 2016 16:23:16 -0000 On 04/08/16 16:48, Phil Hunt (IDM) wrote: > This is as bad as assuming an access token means someone was authenticated. > > In this case the audience of the id token is not the resource and other badness may ensue. I'm not sure what this comment is related to. Did you see what I'm asking about ? I'm repeating that I'm not advocating to use IdTokens as AccessTokens; IdTokens are for the client to interact with the user, AccessTokens are for the client to access RS on behalf of the user. But there's a token exchange draft having a section on the impersonation. There must be a reason it is there. Trying to figure how it is related to the well known tokens (IdToken, AccessToken) Sergey > > Phil > >> On Aug 4, 2016, at 8:17 AM, Sergey Beryozkin wrote: >> >> Hi Phil >> >>> On 04/08/16 15:01, Phil Hunt (IDM) wrote: >>> You might be munging two different flows with different semantics together. >>> >>> First flow is use oidc to authen the user to the client. >>> >>> Second flow is normal oauth authorization to get an at to access the resource. >>> >>> Often the OP AS is different from the RS's AS and the rs needs a proper "delegation" access token. >> Indeed, this is more or less what I've been saying in our private discussions. >> >> But as I said to in my response to Mike, I see a demand to have IdToken propagated and given the token exchange draft has a dedicated 'impersonation' section I'm assuming there's a need for it. >> >> For example, I was checking the archives, could see Brian Campbell quoting Vittorio Bertocci: >> "To summarize our main use case: we use [a token exchange like protocol] for achieving user impersonation thru tiers, or delegation for confidential clients which do not have any web UX..." >> >> The former case there suggests that if a client has a web UI they authenticate the user first and then start impersonating. >> >> I'm advocating for the clients to use the access tokens. The clients can requests the extra scopes while authenticating the user and if the user approves these scopes the client can continue using AT on behalf of the client, and using IdToken to only interact with the user. >> >> But I'm finding it difficult to explain (show a clear differentiator) when the client should use AT and when they should use IdToken to impersonate a user and get a new token (via the token exchange)... >> >> Sergey >>> >>> Phil >>> >>>> On Aug 4, 2016, at 6:00 AM, Mike Schwartz wrote: >>>> >>>> Sergey, >>>> >>>> Since no one answered your question, let me pose a few questions to your questions! >>>> >>>> Wouldn't it give you more flexibility to issue a different token to >>>> represent access to the RS API? In terms of passing user claims, >>>> couldn't this be done via parameters in the API? Are you trying to do >>>> more with OpenID Connect than was anticpiated in the design? >>>> The id_token has an audience, are you including more than one client in that >>>> audience? Would it make sense to look at token exchange and downscope the token? >>>> If you are looking for a profile of OAuth2, might UMA work? >>>> >>>> I think you're not alone in wondering what the answer to all these questions are.. >>>> >>>> - Mike >>>> >>>> >>>> ------------------------------------- >>>> Michael Schwartz >>>> Gluu >>>> http://gluu.org >>>> >>>>> Message: 3 >>>>> Date: Wed, 3 Aug 2016 11:08:29 +0100 >>>>> From: Sergey Beryozkin >>>>> To: "oauth@ietf.org" >>>>> Subject: [OAUTH-WG] Using IdToken instead of Access token >>>>> Message-ID: >>>>> Content-Type: text/plain; charset=windows-1252; format=flowed >>>>> Hi All >>>>> I hope this question is better suited for this list. Will have no >>>>> problems redirecting it to the openid-connect list instead. >>>>> Consider a user working with the client web application (OIDC RP) which >>>>> authenticates the user with the OIDC authorization code flow at the end >>>>> of which the client gets AccessToken + IdToken. Next the user requests >>>>> something from the client which needs to access the RS to complete this >>>>> request. >>>>> And the idea is to have the client pass IdToken to RS and use various >>>>> user claims inside this IdToken to enforce the access control at the RS >>>>> level. My position it is likely wrong but I guess I may be missing >>>>> something that will be either in favor or against it. >>>>> The reason I think it is wrong is that if the client is using a code >>>>> flow then the right approach for staying within the OAuth2 'world' is to >>>>> use the access token to talk to RS and use IdToken only for the purpose >>>>> of interacting with the user. The access token represents a proper user >>>>> authorization and can have the extra scopes in addition to "oidc" which >>>>> RS can depend upon in its access control restrictions. >>>>> Next I'm arguing that if the IdToken is used instead then it is the case >>>>> of the client impersonating the user. And refer to the STS for the REST >>>>> of Us draft (I have a separate series of question on that draft). I'm >>>>> saying the impersonation can work but ignoring the access tokens >>>>> completely will make the overall solution much less flexible. >>>>> I'd like to ask for some advice/guidance: >>>>> - Is it a good idea at all for the client to use IdToken instead of >>>>> AccessToken as explored above ? I suppose it can work, in the code flow >>>>> the client gets the access token which, by default, only allows to >>>>> access UserInfo. Perhaps the client impersonating IdToken for the >>>>> purpose of accessing RS is not too bad after all. >>>>> - Assuming the impersonation is OK, what is the right criteria for the >>>>> client to choose to work with IdToken instead of the access token when >>>>> accessing the immediate RS. It seems like if the impersonation is OK for >>>>> the client to do then why have access tokens at all... >>>>> - Assuming the impersonation is OK, does STS For the REST of Us shows >>>>> the right and the only way it needs to be done ? I can imagine how it >>>>> will work for the web app clients, but what about Implicit Clients. >>>>> Many thanks, Sergey >>>> >>>> _______________________________________________ >>>> 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 >> >> >> -- >> Sergey Beryozkin >> >> Talend Community Coders >> http://coders.talend.com/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Thu Aug 4 09:26:55 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDE112D744 for ; Thu, 4 Aug 2016 09:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 fUKmRm7Po2t7 for ; Thu, 4 Aug 2016 09:26:51 -0700 (PDT) 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 70B5F12D75C for ; Thu, 4 Aug 2016 09:26:51 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id i5so224998wmg.0 for ; Thu, 04 Aug 2016 09:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=LZ4LIhAV14YmVggY9KS7sLY3znKvpMz/0UB+J93JSws=; b=tWj9h2ZkSYpBYrq8iZvNV09U9TPMWmHoLXZiRo8OySic8ZTLxxTyGUmrE+UD7SFaPw YaXs/jlo1sFmKLSzxcSojsJwDNVER+xUfu8vtGYWE7XXIKW4KwkPGFxB/rLgJlHwXQua B7Lh/VTltgkiLex4RVlJOgV+Ol8lZH6oPlAN9BQHYH9SQxrgEcjIJh1FLWN++NwW8QsQ So251KG/aVXKK+mOKYNSSF9H/9mEuKb0UNmLpm/vWJ7zswDdryu//FwrdPR9eLvk0e4h Gobi+t98hBA1bIU1cDKPypjcPS1s5G0CT6Cdoi526bl4gr58ecRSa9tTgiAhJxToh6TB 719g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=LZ4LIhAV14YmVggY9KS7sLY3znKvpMz/0UB+J93JSws=; b=EfuPaLGzpVgfuLW2tWeyJxbEoz6Lo+pZh9o1jSQdOCxTN4T1eEWjFscm86333jh9cn mzjOsYJRatbRMXVa/ZzhMr/HXWMizO8NF0DvYrT/WctzOvU7/rjxs3HmHOT0ZGSvPuIO zMCfs+4suEWzNcGkA1zfevq2wOpL2Jzlft4bZakyRYMpaCtRy5TzUEgAxA3t7LMdALhA B3h1Bs0YBp7kD1OobNDAjsmSwokZFgPuMC4HVRhOpn7JmWEyOD2Q0nOaOXoemxSe/TCF BDLbhVracLrWQ1fFsKiIgTP3CjAXsYQT5OYNMnB0d6sh0BZj8C2iiVaYnIS4DiIZyHvz 6TCA== X-Gm-Message-State: AEkoouu3BIWqDbwaR8yGnmEkvmgJReqwpFk7UQGQ4D8pHGg+lT61Qi9gTGYuBwACOFMNmw== X-Received: by 10.28.153.202 with SMTP id b193mr76417734wme.62.1470328009639; Thu, 04 Aug 2016 09:26:49 -0700 (PDT) Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id a203sm4972232wma.0.2016.08.04.09.26.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Aug 2016 09:26:48 -0700 (PDT) To: John Bradley References: <8F94CB33-41A6-438E-BE15-38A90FE653F5@oracle.com> <6a1e6f1e-16a3-c150-e057-a28a7d5b2b33@gmail.com> <5E317DFF-AE9B-4D18-9281-3C349AB57357@ve7jtb.com> From: Sergey Beryozkin Message-ID: Date: Thu, 4 Aug 2016 17:26:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5E317DFF-AE9B-4D18-9281-3C349AB57357@ve7jtb.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Using IdToken instead of Access token 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, 04 Aug 2016 16:26:54 -0000 Hi John I think it is closer to what I'm trying to understand :-). Let me work with the text below, I'll likely have few more questions to follow later on Thanks, Sergey On 04/08/16 17:04, John Bradley wrote: > The id_token and access token have different semantics, and quite possable possibly formats. > > So the AT that comes with the id_token will be useful at RS associated with the AS, but it may not be useful at other API the client wants to access and that is generally where we run into the use case for token exchange. > > In the case of talking to a third party API it may be useful to have that API have a token exchange endpoint where a client can exchange a id_token/JWT for an access token. > That is clearer and likely more secure given a confidential client than just using the id_token as a access token directly. > > Now I do understand people do that now. > > In the hopefully near future once we have token binding as a proof of possession mechanism it will be come clearer that you cant take a id_token that is bound to the browser presenting the token to the client and directly re use that as a secure access token. The AT and RT issued with that token will be bound to the client so that the RS can validate them. > > There are a lot of bad patterns possible with bearer tokens. I prefer to try to avoid them so that people will be in a better position when we move off bearer tokens for increased security. > > John B. >> On Aug 4, 2016, at 11:17 AM, Sergey Beryozkin wrote: >> >> Hi Phil >> >> On 04/08/16 15:01, Phil Hunt (IDM) wrote: >>> You might be munging two different flows with different semantics together. >>> >>> First flow is use oidc to authen the user to the client. >>> >>> Second flow is normal oauth authorization to get an at to access the resource. >>> >>> Often the OP AS is different from the RS's AS and the rs needs a proper "delegation" access token. >> Indeed, this is more or less what I've been saying in our private discussions. >> >> But as I said to in my response to Mike, I see a demand to have IdToken propagated and given the token exchange draft has a dedicated 'impersonation' section I'm assuming there's a need for it. >> >> For example, I was checking the archives, could see Brian Campbell quoting Vittorio Bertocci: >> "To summarize our main use case: we use [a token exchange like protocol] for achieving user impersonation thru tiers, or delegation for confidential clients which do not have any web UX..." >> >> The former case there suggests that if a client has a web UI they authenticate the user first and then start impersonating. >> >> I'm advocating for the clients to use the access tokens. The clients can requests the extra scopes while authenticating the user and if the user approves these scopes the client can continue using AT on behalf of the client, and using IdToken to only interact with the user. >> >> But I'm finding it difficult to explain (show a clear differentiator) when the client should use AT and when they should use IdToken to impersonate a user and get a new token (via the token exchange)... >> >> Sergey >>> >>> Phil >>> >>>> On Aug 4, 2016, at 6:00 AM, Mike Schwartz wrote: >>>> >>>> Sergey, >>>> >>>> Since no one answered your question, let me pose a few questions to your questions! >>>> >>>> Wouldn't it give you more flexibility to issue a different token to >>>> represent access to the RS API? In terms of passing user claims, >>>> couldn't this be done via parameters in the API? Are you trying to do >>>> more with OpenID Connect than was anticpiated in the design? >>>> The id_token has an audience, are you including more than one client in that >>>> audience? Would it make sense to look at token exchange and downscope the token? >>>> If you are looking for a profile of OAuth2, might UMA work? >>>> >>>> I think you're not alone in wondering what the answer to all these questions are.. >>>> >>>> - Mike >>>> >>>> >>>> ------------------------------------- >>>> Michael Schwartz >>>> Gluu >>>> http://gluu.org >>>> >>>>> Message: 3 >>>>> Date: Wed, 3 Aug 2016 11:08:29 +0100 >>>>> From: Sergey Beryozkin >>>>> To: "oauth@ietf.org" >>>>> Subject: [OAUTH-WG] Using IdToken instead of Access token >>>>> Message-ID: >>>>> Content-Type: text/plain; charset=windows-1252; format=flowed >>>>> Hi All >>>>> I hope this question is better suited for this list. Will have no >>>>> problems redirecting it to the openid-connect list instead. >>>>> Consider a user working with the client web application (OIDC RP) which >>>>> authenticates the user with the OIDC authorization code flow at the end >>>>> of which the client gets AccessToken + IdToken. Next the user requests >>>>> something from the client which needs to access the RS to complete this >>>>> request. >>>>> And the idea is to have the client pass IdToken to RS and use various >>>>> user claims inside this IdToken to enforce the access control at the RS >>>>> level. My position it is likely wrong but I guess I may be missing >>>>> something that will be either in favor or against it. >>>>> The reason I think it is wrong is that if the client is using a code >>>>> flow then the right approach for staying within the OAuth2 'world' is to >>>>> use the access token to talk to RS and use IdToken only for the purpose >>>>> of interacting with the user. The access token represents a proper user >>>>> authorization and can have the extra scopes in addition to "oidc" which >>>>> RS can depend upon in its access control restrictions. >>>>> Next I'm arguing that if the IdToken is used instead then it is the case >>>>> of the client impersonating the user. And refer to the STS for the REST >>>>> of Us draft (I have a separate series of question on that draft). I'm >>>>> saying the impersonation can work but ignoring the access tokens >>>>> completely will make the overall solution much less flexible. >>>>> I'd like to ask for some advice/guidance: >>>>> - Is it a good idea at all for the client to use IdToken instead of >>>>> AccessToken as explored above ? I suppose it can work, in the code flow >>>>> the client gets the access token which, by default, only allows to >>>>> access UserInfo. Perhaps the client impersonating IdToken for the >>>>> purpose of accessing RS is not too bad after all. >>>>> - Assuming the impersonation is OK, what is the right criteria for the >>>>> client to choose to work with IdToken instead of the access token when >>>>> accessing the immediate RS. It seems like if the impersonation is OK for >>>>> the client to do then why have access tokens at all... >>>>> - Assuming the impersonation is OK, does STS For the REST of Us shows >>>>> the right and the only way it needs to be done ? I can imagine how it >>>>> will work for the web app clients, but what about Implicit Clients. >>>>> Many thanks, Sergey >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> -- >> Sergey Beryozkin >> >> Talend Community Coders >> http://coders.talend.com/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ From nobody Thu Aug 4 10:10:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1CC12D641 for ; Thu, 4 Aug 2016 10:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 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=-0.001, RP_MATCHES_RCVD=-1.287, 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 D7SzIIPb4zO2 for ; Thu, 4 Aug 2016 10:10:48 -0700 (PDT) Received: from omr-m005e.mx.aol.com (omr-m005e.mx.aol.com [204.29.186.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5084B12D5C9 for ; Thu, 4 Aug 2016 10:10:48 -0700 (PDT) Received: from mtaout-aaf02.mx.aol.com (mtaout-aaf02.mx.aol.com [172.26.127.98]) by omr-m005e.mx.aol.com (Outbound Mail Relay) with ESMTP id 52571380008A for ; Thu, 4 Aug 2016 13:10:47 -0400 (EDT) Received: from [10.172.104.61] (unknown [10.172.104.61]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aaf02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 4ACAD38000084 for ; Thu, 4 Aug 2016 13:10:46 -0400 (EDT) To: "oauth@ietf.org" From: George Fletcher Organization: AOL LLC Message-ID: Date: Thu, 4 Aug 2016 13:10:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------DFB08887E7183DC08A424E5F" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1470330647; bh=V9qVcYdzeUo1zIvPPyS1wUi1P7R3vX7yre4M6i80mLQ=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=5SP9dI+9zdl8IqV4WDzSo3QUpC2IyLyqeRdrfUS6GZpFUAjgWcUwiUG+O5FIBrwwu YK0cQZ1gDyX4dMUoMEYQD5Crsb8CE8NQ9t0xPovpo/b5WN1SNvGSQ0CfS0stQc+LKU ImrIVNrRAWv9+CXGX9J+G6zrn2KpEcz1Zf2Ww4Ng= x-aol-sid: 3039ac1a7f6257a377162440 X-AOL-IP: 10.172.104.61 Archived-At: Subject: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00 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, 04 Aug 2016 17:10:50 -0000 This is a multi-part message in MIME format. --------------DFB08887E7183DC08A424E5F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Mike, thanks for drafting and publishing these specifications. I have a couple of questions regarding the draft-jones-oauth-resource-metadata-00. 1. Is a "protected resource" a server? or an actual API endpoint. The non-normative examples use /.well-known/oauth-protected-resource and /resource1/.well-known/oauth-protected-resource which is a little unclear. I think of "resource" as something like "Mail" or "Instant Messaging". 2. Assuming that "protected resource" means an actual API endpoint, what is the expected location of the metadata for a fully REST compliant API where the full URL points to a specific resource and not the concept of a general API. Using an example of an IdP that supports user management capabilities. Let's assume the IdP supports a REST API of... CREATE -- POST https://idp.example.com/tenant//users READ -- GET https://idp.example.com/tenant//users/ UPDATE -- PUThttps://idp.example.com/tenant//users/ DELETE -- DELETEhttps://idp.example.com/tenant//users/ Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots of users. Where does the .well-known/oauth-protected-resource get added? ?? https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oauth-protected-resource In this case would not the oauth-protected-resource metadata be duplicated across the set of tenants and users? Is that the desired behavior? Thanks, George --------------DFB08887E7183DC08A424E5F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mike, thanks for drafting and publishing these specifications. I have a couple of questions regarding the draft-jones-oauth-resource-metadata-00.

1. Is a "protected resource" a server? or an actual API endpoint. The non-normative examples use /.well-known/oauth-protected-resource and /resource1/.well-known/oauth-protected-resource which is a little unclear. I think of "resource" as something like "Mail" or "Instant Messaging".

2. Assuming that "protected resource" means an actual API endpoint, what is the expected location of the metadata for a fully REST compliant API where the full URL points to a specific resource and not the concept of a general API.
Using an example of an IdP that supports user management capabilities. Let's assume the IdP supports a REST API of...

    CREATE -- POST https://idp.example.com/tenant/<tenantid>/users
    READ -- GET https://idp.example.com/tenant/<tenantid>/users/<userid>
    UPDATE -- PUT https://idp.example.com/tenant/<tenantid>/users/<userid>
    DELETE -- DELETE https://idp.example.com/tenant/<tenantid>/users/<userid>

Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots of users. Where does the .well-known/oauth-protected-resource get added?

   ?? https://idp.example.com/tenant/tenantA/users/1232234/.well-known/oauth-protected-resource

In this case would not the oauth-protected-resource metadata be duplicated across the set of tenants and users? Is that the desired behavior?
Thanks,
George
 

  


--------------DFB08887E7183DC08A424E5F--


From nobody Thu Aug  4 10:17:11 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856C412DAB1 for ; Thu,  4 Aug 2016 10:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level: 
X-Spam-Status: No, score=-3.187 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=-0.001, RP_MATCHES_RCVD=-1.287, 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 Vzcw2RYzBpHF for ; Thu,  4 Aug 2016 10:17:07 -0700 (PDT)
Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D47712DAA8 for ; Thu,  4 Aug 2016 10:17:07 -0700 (PDT)
Received: from mtaout-aaa02.mx.aol.com (mtaout-aaa02.mx.aol.com [172.27.1.226]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 6F4B43800174; Thu,  4 Aug 2016 13:17:06 -0400 (EDT)
Received: from [10.172.104.61] (unknown [10.172.104.61]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aaa02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id E3F2738000096; Thu,  4 Aug 2016 13:17:05 -0400 (EDT)
To: Hannes Tschofenig , "oauth@ietf.org" 
References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <636050cf-3def-8e9d-ed3d-0833840b1c24@aol.com>
Date: Thu, 4 Aug 2016 13:17:08 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <33052033-0992-ceb8-4390-6837017b140e@gmx.net>
Content-Type: multipart/alternative; boundary="------------A61A65F656744FB2C4D7E6B3"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1470331026; bh=JG+wGdtwdwazMRsJ5Jq+lqgGcS9zb9E5TCKbZq+sw+4=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=dvDfDQNCHbhp8l84tk1xxFL4vbYHAAeWNHviu+E5kCMKhq5EnEDBj3aBFQyFttg2Z EhNvv9DGSn8K3O9QHKIbTKu9DXQ1ZRmjz+AgYe6V6xRDwbNbYSFe45GOfKOSS6xUMk jha+dPF3dyOL+rmy9Yu7iGRvU69jhsygMCJr/s4w=
x-aol-sid: 3039ac1b01e257a37891033e
X-AOL-IP: 10.172.104.61
Archived-At: 
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
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, 04 Aug 2016 17:17:10 -0000

This is a multi-part message in MIME format.
--------------A61A65F656744FB2C4D7E6B3
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

I accept these documents as a starting point of the Token binding work in OAuth.

George

On 8/3/16 3:45 AM, Hannes Tschofenig wrote:
> Hi all,
>
> this is the call for adoption of the 'OAuth 2.0 Token Binding' document
> bundle* following the positive call for adoption at the recent IETF
> meeting in Berlin.
>
> Here are the links to the documents presented at the last IETF meeting:
> https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
> https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
>
> Please let us know by August 17th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Derek
>
> *: We will find out what the best document structure is later, i.e.,
> whether the content should be included in one, two or multiple documents.
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------A61A65F656744FB2C4D7E6B3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
I accept these documents as a starting point of the Token binding work in OAuth.

    George

    

    
On 8/3/16 3:45 AM, Hannes Tschofenig
      wrote:

    

    

      
Hi all,

this is the call for adoption of the 'OAuth 2.0 Token Binding' document
bundle* following the positive call for adoption at the recent IETF
meeting in Berlin.

Here are the links to the documents presented at the last IETF meeting:
https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00

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

Ciao
Hannes & Derek

*: We will find out what the best document structure is later, i.e.,
whether the content should be included in one, two or multiple documents.



      

      

      

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


    

    

  


--------------A61A65F656744FB2C4D7E6B3--


From nobody Thu Aug  4 11:54:31 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8256712D778 for ; Thu,  4 Aug 2016 11:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.889
X-Spam-Level: 
X-Spam-Status: No, score=-103.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 YqcwCEczTMOw for ; Thu,  4 Aug 2016 11:54:27 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD62312D748 for ; Thu,  4 Aug 2016 11:54:27 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id B0844B80BDA; Thu,  4 Aug 2016 11:54:27 -0700 (PDT)
To: ietf@justin.richer.org, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, Hannes.Tschofenig@gmx.net, derek@ihtfp.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20160804185427.B0844B80BDA@rfc-editor.org>
Date: Thu,  4 Aug 2016 11:54:27 -0700 (PDT)
Archived-At: 
Cc: oauth@ietf.org, rfc-editor@rfc-editor.org
Subject: [OAUTH-WG] [Editorial Errata Reported] RFC7662 (4764)
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, 04 Aug 2016 18:54:29 -0000

The following errata report has been submitted for RFC7662,
"OAuth 2.0 Token Introspection".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7662&eid=4764

--------------------------------------
Type: Editorial
Reported by: Brian Campbell 

Section: 3.1

Original Text
-------------
OAuth registration client metadata names and descriptions are
registered by

Corrected Text
--------------
OAuth token introspection response parameters are registered by

Notes
-----
The original text erroneously mentions registration of client metadata names, however, this RFC 7662 is about about token introspection and this section is about registration of token introspection response parameters (client metadata name registration is RFC 7591).

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 (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7662 (draft-ietf-oauth-introspection-11)
--------------------------------------
Title               : OAuth 2.0 Token Introspection
Publication Date    : October 2015
Author(s)           : J. Richer, Ed.
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Thu Aug  4 13:13:07 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9A412D7EC for ; Thu,  4 Aug 2016 13:13:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vde-1yUY9yFa for ; Thu,  4 Aug 2016 13:13:04 -0700 (PDT)
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 03E3F12D150 for ; Thu,  4 Aug 2016 13:13:03 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id p74so243674355qka.0 for ; Thu, 04 Aug 2016 13:13:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=2sYY2+AeaG6D4FKmMzs+6fWfBzrCDIec26qNGqlQXoU=; b=eJkeaJmYGMNXQlwLis9QW1uDmSpOCPhIgPeD4DsHRUIVa3M8a/HeGI60ctjkY1p5CG Zo0hocFlT4J80r9zBzSxblXbbr1MCczVCUYsBkRHiUTc5vWk4b3+9vQPUZ3Bjl4Z/dLf WwRmFF4mLi1r5qluCIbQ5+mHyVVMQJsqDLIUfkrHOE5SG2WAeM5k/zmT+nexTU7I7doo oonz65XMX5Y6IQAFyh9+Tqt7kpfR/QcJNFpAH3qtY+CXxls8U/ckSEWqq3FiXdBC5LkY 0AoYbKaFdOZjniewXQHWRhn8NyJsHSzGt/D3rYY/Ctuf3wFmcCWSW3ex0F3SjhrbxtJ2 keTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2sYY2+AeaG6D4FKmMzs+6fWfBzrCDIec26qNGqlQXoU=; b=OwVM3xubM49NqV3pYyOpAkgjqFZ1dtld47howd49StcthEuYWbyB91+OwXcMykRTpo E2r8MpLBWFi+7L+vOtTtfUtjTTYPSY04AkWfy+0xxNmqVabCToMDHG9/pdfuoPqCsf2i +piiHNDy0QxJKn1FdgUMMJUSv7bm1Rl5XtB1GKWxmMRrS3CQTZT2ptUH/YAsMIJMgBS2 WCy/Lf7lPMTtkbj7vyueNfzjyRN8b3Kz9/3UzBn7U4TMpvvy7W+4S1oZENABwy26SXKj 2eNHh33VZM92YygvzhfVbdP/vvf2ezZ8zx/Faerx8hmM88A6ZVHhIzEJjSvIfsVDG7He y/zw==
X-Gm-Message-State: AEkoousozGJrPkMPR2hPHShduKHLvKKJ2xogV91XB1vW4/LDOvpoUGg1pp0uwjxaATecWKB2
X-Received: by 10.55.42.169 with SMTP id q41mr8364966qkq.250.1470341582887; Thu, 04 Aug 2016 13:13:02 -0700 (PDT)
Received: from [192.168.8.100] ([181.201.90.86]) by smtp.gmail.com with ESMTPSA id h186sm7783421qke.49.2016.08.04.13.13.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Aug 2016 13:13:02 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DB2D8DEC-9C95-4D58-A79B-D20553A7D095"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: <52f75ab0-9072-49dd-635b-da5de4014312@connect2id.com>
Date: Thu, 4 Aug 2016 16:12:59 -0400
Message-Id: <3B1ED07C-6BF9-44DA-BC05-ACD5AFF63868@ve7jtb.com>
References:  <52f75ab0-9072-49dd-635b-da5de4014312@connect2id.com>
To: Vladimir Dzhuvinov 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Metadata Specifications Enhanced
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, 04 Aug 2016 20:13:06 -0000

--Apple-Mail=_DB2D8DEC-9C95-4D58-A79B-D20553A7D095
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

This was proposed =
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01 =


It seemed to be a bit too controversial for the WG to accept at the time =
it was discussed.

John B.
> On Aug 4, 2016, at 6:33 AM, Vladimir Dzhuvinov =
 wrote:
>=20
> Thanks Mike for the updates.
>=20
> These two specs (along with token exchange and perhaps others) =
effectively codify "resource" as a key OAuth 2.0 property and parameter, =
alongside "scope". RFC 6749 however only specifies "scope" in authz and =
token requests.
>=20
> Have there been any thoughts how to reconcile this?
>=20
> Vladimir
>=20
> On 03/08/16 23:57, Mike Jones wrote:
>> The existing OAuth 2.0 Authorization Server =
Metadata =
 specification =
has now been joined by a related OAuth 2.0 Protected Resource =
Metadata =
 =
specification.  This means that JSON metadata formats are now defined =
for all the OAuth 2.0 parties: clients, authorization servers, and =
protected resources.
>>=20
>> The most significant addition to the OAuth 2.0 Authorization Server =
Metadata specification is enabling signed metadata, represented as =
claims in a JSON Web Token (JWT).  This is analogous to the role that =
the Software Statement plays in OAuth Dynamic Client Registration.  =
Signed metadata can also be used for protected resource metadata.
>>=20
>> For use cases in which the set of protected resources used with an =
authorization server are enumerable, the authorization server metadata =
specification now defines the "protected_resources" metadata value to =
list them.  Likewise, the protected resource metadata specification =
defines an "authorization_servers" metadata value to list the =
authorization servers that can be used with a protected resource, for =
use cases in which those are enumerable.
>>=20
>> The specifications are available at:
>>=20
>> *       http://tools.ietf.org/html/draft-ietf-oauth-discovery-04 =

>>=20
>> *       =
http://tools.ietf.org/html/draft-jones-oauth-resource-metadata-00 =

>>=20
>> HTML-formatted versions are also available at:
>>=20
>> *       =
http://self-issued.info/docs/draft-ietf-oauth-discovery-04.html =

>>=20
>> *       =
http://self-issued.info/docs/draft-jones-oauth-resource-metadata-00.html =
=

>>=20
>>                                                        -- Mike
>>=20
>> P.S.  This notice was also posted at http://self-issued.info/?p=3D1591 =
 and as =
@selfissued =
.
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

>=20
> --=20
> Vladimir Dzhuvinov
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_DB2D8DEC-9C95-4D58-A79B-D20553A7D095
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=windows-1252

This was proposed https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01

It seemed to be a bit too controversial for the WG to accept at the time it was discussed.

John B.
On Aug 4, 2016, at 6:33 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:


  
    
  
  
Thanks Mike for the updates.
These two specs (along with token exchange and perhaps others)
      effectively codify "resource" as a key OAuth 2.0 property and
      parameter, alongside "scope". RFC 6749 however only specifies
      "scope" in authz and token requests.
Have there been any thoughts how to reconcile this?
Vladimir

    


    

    
On 03/08/16 23:57, Mike Jones wrote:

    

    

      
The existing OAuth 2.0 Authorization Server Metadata<https://tools.ietf.org/html/draft-ietf-oauth-discovery> specification has now been joined by a related OAuth 2.0 Protected Resource Metadata<https://tools.ietf.org/html/draft-jones-oauth-resource-metadata> specification.  This means that JSON metadata formats are now defined for all the OAuth 2.0 parties: clients, authorization servers, and protected resources.

The most significant addition to the OAuth 2.0 Authorization Server Metadata specification is enabling signed metadata, represented as claims in a JSON Web Token (JWT).  This is analogous to the role that the Software Statement plays in OAuth Dynamic Client Registration.  Signed metadata can also be used for protected resource metadata.

For use cases in which the set of protected resources used with an authorization server are enumerable, the authorization server metadata specification now defines the "protected_resources" metadata value to list them.  Likewise, the protected resource metadata specification defines an "authorization_servers" metadata value to list the authorization servers that can be used with a protected resource, for use cases in which those are enumerable.

The specifications are available at:

*       http://tools.ietf.org/html/draft-ietf-oauth-discovery-04

*       http://tools.ietf.org/html/draft-jones-oauth-resource-metadata-00

HTML-formatted versions are also available at:

*       http://self-issued.info/docs/draft-ietf-oauth-discovery-04.html

*       http://self-issued.info/docs/draft-jones-oauth-resource-metadata-00.html

                                                       -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1591 and as @selfissued<https://twitter.com/selfissued>.



      

      

      

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


    

    

    
-- 
Vladimir Dzhuvinov

  


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


--Apple-Mail=_DB2D8DEC-9C95-4D58-A79B-D20553A7D095--


From nobody Thu Aug  4 13:15:41 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5600112D79F for ; Thu,  4 Aug 2016 13:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TewR49_Qy5MS for ; Thu,  4 Aug 2016 13:15:37 -0700 (PDT)
Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) (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 3CD4812D5A9 for ; Thu,  4 Aug 2016 13:15:37 -0700 (PDT)
Received: from [192.168.19.103] ([109.160.89.229]) by :SMTPAUTH: with SMTP id VP2mbcbINUqfEVP2nbNKHp; Thu, 04 Aug 2016 13:15:06 -0700
To: Nat Sakimura , oauth@ietf.org
References: <20160804035457.9671.15892.idtracker@ietfa.amsl.com> <102ec164-bc1a-cc35-820b-fa9ceb237b1c@connect2id.com> <02cf01d1ee3f$65c8e4f0$315aaed0$@nri.co.jp>
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: 
Date: Thu, 4 Aug 2016 23:15:03 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <02cf01d1ee3f$65c8e4f0$315aaed0$@nri.co.jp>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010606030304020908050509"
X-CMAE-Envelope: MS4wfD8Kr5LplEwJm6mrsqp78K7dHq51ODhn8jP4d6nayVi3REGhNP7uSuQab9utd8mzsLEK8N8+8KO7iz2YV7cyU0BcvFO4ZvlmlTClnu3YH3+qkV+WWa3r aG8UrtFjfMMljF2rYOsWQ6JTXbDODvjs7lGQFlUQfMWRfdGwKB+12rzsHB41kGesFAMqWyWmwaL5SodGKgTRI53zbzYkPLeIo/s=
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.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, 04 Aug 2016 20:15:39 -0000

This is a cryptographically signed message in MIME format.

--------------ms010606030304020908050509
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi Nat,


On 04/08/16 14:00, Nat Sakimura wrote:
>
>> 1. alg:none request JWTs being no longer permitted
>
> I think it is a bug of the OpenID Connect Core 1.0.=20
>
> =20
>
> Request Object itself can be alg=3Dnone in OAuth JAR draft 08 as well. =

>
> =20
>
> If alg=3Dnone, it MUST NOT be passed by value using `request` parameter=
=2E=20
>
> It is fine to be that way as long as you pass it by reference.=20
>
> =20
>
> Like OAuth JAR draft-08, OpenID Connect used to have a section dedicate=
d to
> "Request Object" if I remember correctly. However, during the re-factor=
ing,
> it was subsumed in "5.5.  Requesting Claims using the "claims" Request
> Parameter" and the statement about allowing alg=3Dnone in Request Objec=
t that
> are passed by value sneaked in there.=20
>
> =20
>
> I am going to file a bug report for OpenID Connect on this.=20
>
> =20
>
> Or, do you have any specific use case for keeping "alg=3Dnone" for the
> "passing by value" case?

An "alg:none" request object has no value if it's passed by value, so
yes, in that sense we can call it a bug.

The only potential use case I see for "alg:none" is clients that can't
handle crypto but may be able to pass the JWT via a HTTPS URL (perhaps
preregistered).


BTW, I don't see request URI registration mentioned, and this is quite a
significant feature, especially in dynamic scenarios.


>
>> 2. HTTPS request_uri's becoming always required, though there is confu=
sion
> about that (see below).
>
> =20
>
> I should remove the statement in 5.2.1., as it just meant to have repea=
ted
> what it was said in 5.2.=20
>
> =20
I see.

> I should also add further condition in 5.2. so that it becomes:=20
>
> =20
>
> ```
>
> unless the target Request Object is signed in a way that is
>
> verifiable by the Authorization Server and the channel is=20
>
> protected so that network attacker cannot observe.=20
>
> ```
>
> =20
>
> What do you think?=20
On the 1st condition - HMAC - protected or signed request object to
ensure authenticity - ok, this is a must if the JWT is fed via plain
HTTP, to ensure the parameters cannot be tampered with.

On the 2nd condition - do you mean encrypting the JWT, or something else?=


> =20
>
> Nat
>
> =20
>
> --
>
> 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.
>
> =20
>
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir Dzhuv=
inov
> Sent: Thursday, August 4, 2016 6:59 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt
>
> =20
>
> Thanks Nat.
>
> It looks like draft-ietf-oauth-jwsreq-08.txt is breaking with OpenID Co=
nnect
> in regard to
>
> 1. alg:none request JWTs being no longer permitted
>
> 2. HTTPS request_uri's becoming always required, though there is confus=
ion
> about that (see below).
>
>
>
> I don't know if this is intentional.
>
>
>
> Quoting the original Connect spec on alg:none:
>
> http://openid.net/specs/openid-connect-core-1_0.html#RequestObject
>
> ```
> The Request Object MAY be signed or unsigned (plaintext). When it is
> plaintext, this is indicated by use of the none algorithm
>  [JWA] in the=
 JOSE
> Header.=20
> ```
>
>
> There is also confusion about the requirement to have HTTPS, which in 5=
=2E2 is
> conditionally required, and in 5.2.1 always required (the 5.2.1 edit
> appeared in -08).
>
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2
>
> ```
>
> The contents of the resource referenced by the URL MUST be a Request
> Object.  The scheme used in the "request_uri" value MUST be "https",
> unless the target Request Object is signed in a way that is
> verifiable by the Authorization Server.=20
> ```
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2.1
>
> ```
>
> The URL MUST be HTTPS URL.
>
> ```
>
>
> Cheers,
>
> Vladimir
>
>

--=20
Vladimir Dzhuvinov :: vladimir@connect2id.com



--------------ms010606030304020908050509
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhBvIAvByRn0gXptBJbNZg3jMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTYwNDA1MDAwMDAwWhcNMTcwNDA1MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAL/GlaryvhrL+eLYe+8Pv6D/sITLb5c2D5oaq6drPbcqP06xnyLgeFlIwzshIHi5+/Ib
fwSSXRzCDihXBfPlbv2Yf7C0F7QwUYNnqvxfnIZvu/6YFXkWt6Z5h5wvnbFmHWZBiBM8cEMP
qdT7myXDKuHSYvpiCFnIAHJOeoyBRV1I8kyupPe9aBkcYmwAyMjMRgeR92iV4TfTSx4CMRax
OHwa+WUAc2mjWiZOxyxTByORzm2wB2izX/DoeSwcN9mliRAZQ3eBXQD/HoO0LBIX3MXCp9Ry
wHIhz+Qy3mR0VgUu2gGu1r0lLIGwxKE4kEO1I7aBf5hQK/wVKcMyMMpNnU0CAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSCdqr1QGt7
r/f9VkCCmYSI3t5aDjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAFClbz5g+/TKUP9zpmoRdZymgYrU
fgq1UlnzLcgI3IH46LaMMMzUCRn7tz8OM2igQEqpSW9u80W3jaYsRLUdySvE6Jxr9xVPVDGu
JMAenNDS3sgNsKvUcCIeQYYTG4/oYTcuV6jtXTSDK0Y8NQ0pNEg8BnQz3V+nPXYC3/CWoFQ+
4InVPLGTZedK+yev6ee6wWWL3neskkSsYpwW1qTWtjHQcNw2eBphxRq5aNM9F3wKGdkUHKUJ
4mof2ckALH5SO/n0GGR58cgrtfuD/fcqvfsTtiMCHk6oW2ZE5Ty93aDvEhYo5RrA0TpFGoOA
m33FY3lP8EGzGel61qKU5nDH1hUxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBvIAvByRn0gXptBJbNZg3jMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjA4MDQyMDE1MDNaMC8GCSqGSIb3DQEJBDEiBCBw7qezX1wTcJlEEYw+/4foE+dbLOPi
SzR36V4hjFGdpzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQCWhZd/+hjS
OZOrlWty9st6NuAmvwDxxOyKH+b4v0/+JPBB6LxvVG/DC06KK0dZgIJPsAV/5rGTogKZYHBL
U6AKzMjy3lvszvkVzPrOPyN9dcNdV267V33NT2WwSDJBMQcpFsbCPXnpOVDophHcY8ugfvJJ
DuWz5Yu78y3ECbYWoud01sDWAhUrA30NWt6S69jysiLgDa1/EPRGAn9TawJ2qtwfmrfIOMUt
MzINwTXCoWjL5Om5xslduAExLa++ZRG5zbVomFgdPHVc3mmRSH9AUaCo9TtXTZO1hY0l9zqO
BBxqQ1SP0LDsqpEMq2+9fUQj/gnoFU2oykJBa6XttdkgAAAAAAAA
--------------ms010606030304020908050509--


From nobody Thu Aug  4 13:58:33 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE8612D51A for ; Thu,  4 Aug 2016 13:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3FSlU0c5do6 for ; Thu,  4 Aug 2016 13:58:28 -0700 (PDT)
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 EF6F212D0F4 for ; Thu,  4 Aug 2016 13:58:27 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id x185so52588373qkc.2 for ; Thu, 04 Aug 2016 13:58:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=COMRcs2g7m99OY5kVJIgIo2ZeOVZM8Jy0xHgTNWmdLU=; b=cCvL5x828HCOxSl7wbXJssD36T9y940HAhRowq7LIyC7acOuWCYmwHBEuiPZABKgzq 3xTn8tueVlAaU+XekJ9NE/8X1mzJh2B0m3jF4IFdQCjx1k8SXMtDWSo4PJrzZZjignsE yvYGDR79Hnw/+MaUGFwtGNbDtMfc9BkhujNBDTi9rClyY2NT7R1jcBJjFwX6ychByPt0 25RuzuMDx5dy3QJbofRCcS/tYarqhpUKvIMe4sIDe4PsGmxtd7g2NsVtgBOA6ZKvNbXi RrZZMNvENlMcJwA8849doD1HYwaEK1xsKdIGFmLxnyEOGLt/Z99yVM7wcQXWh2lG+s/A n+PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=COMRcs2g7m99OY5kVJIgIo2ZeOVZM8Jy0xHgTNWmdLU=; b=OF4NY4pQxCIWTBze17XRJGZyA2mM1vwSAQF1FSM8NX2CcSiqmaBU3DljCAzOk/Npc/ NOy2GUcb1UbJdUR1VTKXvs1zWMzBXP4Vg84OyE/5oRKS7GD+SlN4oSckYryhDlW/V4wV gJ4tUZrQc6ABdLnEooXFg6tfwZNrhFvU67eCVhRdh+WGc9ZsQPhHZpgLNSpuLy0/CGoo M52nlGhBMg3MxRVBFpWzYNA7yFDk84swEJCrl9rM6vx0pCtBpKIHelX3r7SRuy5vptaR Fl+ofeH762fekUymWIK3IYxBbsjk1/AHdwtYleJBJjqjXUSnUhqkybbXbu4w7ns3Dbmg Yjag==
X-Gm-Message-State: AEkooutVNd+bsOE6h/h9acdnof4xa5rAggoaOaT7xP4jE6QPKYhqjWXi8cCWIWhKKaQdiwzu
X-Received: by 10.55.167.69 with SMTP id q66mr8621262qke.287.1470344306775; Thu, 04 Aug 2016 13:58:26 -0700 (PDT)
Received: from [192.168.8.100] ([181.201.90.86]) by smtp.gmail.com with ESMTPSA id t42sm7892147qte.24.2016.08.04.13.58.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Aug 2016 13:58:26 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 4 Aug 2016 16:58:20 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DE586FF-3450-4664-8CBC-85632B87A54D@ve7jtb.com>
References:   <8F94CB33-41A6-438E-BE15-38A90FE653F5@oracle.com> <6a1e6f1e-16a3-c150-e057-a28a7d5b2b33@gmail.com> <5E317DFF-AE9B-4D18-9281-3C349AB57357@ve7jtb.com> 
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using IdToken instead of Access token
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, 04 Aug 2016 20:58:31 -0000

The token exchange spec allows for the token issued to have claims about =
the subject of the input token.   This is what we generally think about =
as impersonation.  =20
That is really the same as a normal OAuth access token for the most =
part.

You can also ask for a composite token that contains claims about the =
presenter and the original subject.   This allows for the auditing of =
who is making the request for the subject.

This sort of composite token was introduced in WS-Trust 1.4 and is =
called ActAs in that spec and we refer to as delegation.

This is desired when a RS (A) receives a access token and then needs to =
become a client (A) to access another service in the context of the =
access token. =20

The second RS (B) is protected and can=92t be access directly by the the =
original OAuth client.  The client (A) needs a new access token based on =
its client credential plus the original access token to get a token that =
RS (B)  will accept.   RS (B) also wants to know who the client that is =
accessing it for audit or other reasons.  =20

That is one of the things that the new delegated token type is for.  The =
impersonation type is basically the same sort of impersonation type =
token that we use now.

I admit that OAuth is vague about delegation vs impersonation and they =
are generally left as implementation decisions as the tokens are =
considered opaque.

For token exchange we wanted to be more explicit so that the client has =
more control over the exchange.

I hope that helps.

John B.

> On Aug 4, 2016, at 12:26 PM, Sergey Beryozkin  =
wrote:
>=20
> Hi John
>=20
> I think it is closer to what I'm trying to understand :-). Let me work =
with the text below, I'll likely have few more questions to follow later =
on
>=20
> Thanks, Sergey
>=20
> On 04/08/16 17:04, John Bradley wrote:
>> The id_token and access token have different semantics, and quite =
possable possibly formats.
>>=20
>> So the AT that comes with the id_token will be useful at RS =
associated with the AS, but it may not be useful at other API the client =
wants to access and that is generally where we run into the use case for =
token exchange.
>>=20
>> In the case of talking to a third party API it may be useful to have =
that API have a token exchange endpoint where a client can exchange a =
id_token/JWT for an access token.
>> That is clearer and likely more secure given a confidential client  =
than just using the id_token as a access token directly.
>>=20
>> Now I do understand people do that now.
>>=20
>> In the hopefully near future once we have token binding as a proof of =
possession mechanism it will be come clearer that you cant take a =
id_token that is bound to the browser presenting the token to the client =
and directly re use that as a secure access token.   The AT and RT =
issued with that token will be bound to the client so that the RS can =
validate them.
>>=20
>> There are a lot of bad patterns possible with bearer tokens.   I =
prefer to try to avoid them so that people will be in a better position =
when we move off bearer tokens for increased security.
>>=20
>> John B.
>>> On Aug 4, 2016, at 11:17 AM, Sergey Beryozkin  =
wrote:
>>>=20
>>> Hi Phil
>>>=20
>>> On 04/08/16 15:01, Phil Hunt (IDM) wrote:
>>>> You might be munging two different flows with different semantics =
together.
>>>>=20
>>>> First flow is use oidc to authen the user to the client.
>>>>=20
>>>> Second flow is normal oauth authorization to get an at to access =
the resource.
>>>>=20
>>>> Often the OP AS is different from the RS's AS and the rs needs a =
proper "delegation" access token.
>>> Indeed, this is more or less what I've been saying in our private =
discussions.
>>>=20
>>> But as I said to in my response to Mike, I see a demand to have =
IdToken propagated and given the token exchange draft has a dedicated =
'impersonation' section I'm assuming there's a need for it.
>>>=20
>>> For example, I was checking the archives, could see Brian Campbell =
quoting Vittorio Bertocci:
>>> "To summarize our main use case: we use [a token exchange like =
protocol] for achieving user impersonation thru tiers, or delegation for =
confidential clients which do not have any web UX..."
>>>=20
>>> The former case there suggests that if a client has a web UI they =
authenticate the user first and then start impersonating.
>>>=20
>>> I'm advocating for the clients to use the access tokens. The clients =
can requests the extra scopes while authenticating the user and if the =
user approves these scopes the client can continue using AT on behalf of =
the client, and using IdToken to only interact with the user.
>>>=20
>>> But I'm finding it difficult to explain (show a clear =
differentiator) when the client should use AT and when they should use =
IdToken to impersonate a user and get a new token (via the token =
exchange)...
>>>=20
>>> Sergey
>>>>=20
>>>> Phil
>>>>=20
>>>>> On Aug 4, 2016, at 6:00 AM, Mike Schwartz  wrote:
>>>>>=20
>>>>> Sergey,
>>>>>=20
>>>>> Since no one answered your question, let me pose a few questions =
to your questions!
>>>>>=20
>>>>> Wouldn't it give you more flexibility to issue a different token =
to
>>>>> represent access to the RS API? In terms of passing user claims,
>>>>> couldn't this be done via parameters in the API? Are you trying to =
do
>>>>> more with OpenID Connect than was anticpiated in the design?
>>>>> The id_token has an audience, are you including more than one =
client in that
>>>>> audience? Would it make sense to look at token exchange and =
downscope the token?
>>>>> If you are looking for a profile of OAuth2, might UMA work?
>>>>>=20
>>>>> I think you're not alone in wondering what the answer to all these =
questions are..
>>>>>=20
>>>>> - Mike
>>>>>=20
>>>>>=20
>>>>> -------------------------------------
>>>>> Michael Schwartz
>>>>> Gluu
>>>>> http://gluu.org
>>>>>=20
>>>>>> Message: 3
>>>>>> Date: Wed, 3 Aug 2016 11:08:29 +0100
>>>>>> From: Sergey Beryozkin 
>>>>>> To: "oauth@ietf.org" 
>>>>>> Subject: [OAUTH-WG] Using IdToken instead of Access token
>>>>>> Message-ID: 
>>>>>> Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed
>>>>>> Hi All
>>>>>> I hope this question is better suited for this list. Will have no
>>>>>> problems redirecting it to the openid-connect list instead.
>>>>>> Consider a user working with the client web application (OIDC RP) =
which
>>>>>> authenticates the user with the OIDC authorization code flow at =
the end
>>>>>> of which the client gets AccessToken + IdToken. Next the user =
requests
>>>>>> something from the client which needs to access the RS to =
complete this
>>>>>> request.
>>>>>> And the idea is to have the client pass IdToken to RS and use =
various
>>>>>> user claims inside this IdToken to enforce the access control at =
the RS
>>>>>> level. My position it is likely wrong but I guess I may be =
missing
>>>>>> something that will be either in favor or against it.
>>>>>> The reason I think it is wrong is that if the client is using a =
code
>>>>>> flow then the right approach for staying within the OAuth2 =
'world' is to
>>>>>> use the access token to talk to RS and use IdToken only for the =
purpose
>>>>>> of interacting with the user. The access token represents a =
proper user
>>>>>> authorization and can have the extra scopes in addition to "oidc" =
which
>>>>>> RS can depend upon in its access control restrictions.
>>>>>> Next I'm arguing that if the IdToken is used instead then it is =
the case
>>>>>> of the client impersonating the user. And refer to the STS for =
the REST
>>>>>> of Us draft (I have a separate series of question on that draft). =
I'm
>>>>>> saying the impersonation can work but ignoring the access tokens
>>>>>> completely will make the overall solution much less flexible.
>>>>>> I'd like to ask for some advice/guidance:
>>>>>> - Is it a good idea at all for the client to use IdToken instead =
of
>>>>>> AccessToken as explored above ? I suppose it can work, in the =
code flow
>>>>>> the client gets the access token which, by default, only allows =
to
>>>>>> access UserInfo. Perhaps the client impersonating IdToken for the
>>>>>> purpose of accessing RS is not too bad after all.
>>>>>> - Assuming the impersonation is OK, what is the right criteria =
for the
>>>>>> client to choose to work with IdToken instead of the access token =
when
>>>>>> accessing the immediate RS. It seems like if the impersonation is =
OK for
>>>>>> the client to do then why have access tokens at all...
>>>>>> - Assuming the impersonation is OK, does STS For the REST of Us =
shows
>>>>>> the right and the only way it needs to be done ? I can imagine =
how it
>>>>>> will work for the web app clients, but what about Implicit =
Clients.
>>>>>> Many thanks, Sergey
>>>>>=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
>>>=20
>>>=20
>>> --
>>> Sergey Beryozkin
>>>=20
>>> Talend Community Coders
>>> http://coders.talend.com/
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
>=20
> --=20
> Sergey Beryozkin
>=20
> Talend Community Coders
> http://coders.talend.com/


From nobody Thu Aug  4 23:09:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F005B12D0E9 for ; Thu,  4 Aug 2016 23:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsfi0upoRULe for ; Thu,  4 Aug 2016 23:09:43 -0700 (PDT)
Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) (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 50E9412B05E for ; Thu,  4 Aug 2016 23:09:43 -0700 (PDT)
Received: from [192.168.19.103] ([109.160.89.229]) by :SMTPAUTH: with SMTP id VYJhbdis6UqfEVYJjbNmFk; Thu, 04 Aug 2016 23:09:12 -0700
To: Nat Sakimura , oauth@ietf.org
References: <20160804035457.9671.15892.idtracker@ietfa.amsl.com> <102ec164-bc1a-cc35-820b-fa9ceb237b1c@connect2id.com> <63052b93-b6f4-798b-2774-fa708d5a66af@connect2id.com> <02d401d1ee40$881b1950$98514bf0$@nri.co.jp>
From: Vladimir Dzhuvinov 
Organization: Connect2id Ltd.
Message-ID: <54c0c445-2001-9ffe-a2db-15ec275bc154@connect2id.com>
Date: Fri, 5 Aug 2016 09:09:08 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <02d401d1ee40$881b1950$98514bf0$@nri.co.jp>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010405010608000707020007"
X-CMAE-Envelope: MS4wfMKYojqyeuMzps0x1Cr6W68eYyhViZSJH2nveEKBqQdeGbbDwL/Cv1ovHeanzfTyQiaK1mKu9B5F5o3LguUnfh186LidVCoJzNDfavWx6J9bW92i0pBj fVtMrW2gmjHZjNVrOVc/KSftlv8bHsL772lZ7FWjNy1UlU3mA6W4UJEGIfF36r4Epku9BpZMtuH2iUOqnNSkHTn/GCovPXkniqI=
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.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, 05 Aug 2016 06:09:45 -0000

This is a cryptographically signed message in MIME format.

--------------ms010405010608000707020007
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On 04/08/16 14:08, Nat Sakimura wrote:
> Hi.=20
>
> =20
>
> I am open to change, but I would like to have a nice abbreviation as we=
ll.=20
>
> =20
>
> What about the following?=20
>
> =20
>
> The OAuth 2.0 Authorization Framework: JWT Secured Authorization Reques=
t
> (JAR)
>
> =20
This is a good suggestion, I find this more descriptive, and it fits the
title pattern of RFC 6749 and RFC 6750.

JWT should probably be spelled in full though (this seems to be the
practice).

Vladimir


> Best,=20
>
> =20
>
> Nat
>
> =20
>
> --
>
> 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.
>
> =20
>
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir Dzhuv=
inov
> Sent: Thursday, August 4, 2016 7:15 PM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt
>
> =20
>
> I would like to propose a slight change of the spec title.
>
> =20
>
> From
>
> OAuth 2.0 JWT Authorization Request
>
> =20
>
> to=20
>
> JSON Web Token (JWT) Secured OAuth 2.0 Authorization Request
>
> =20
>
> The current title is not particularly descriptive, and may even read as=
 if
> the spec is about requesting a JWT.
>
> =20
>
> Thanks,
>
> =20
>
> Vladimir
>
> =20
>
> =20
>

--=20
Vladimir Dzhuvinov :: vladimir@connect2id.com



--------------ms010405010608000707020007
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CfwwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVFMIIELaADAgECAhBvIAvByRn0gXptBJbNZg3jMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTYwNDA1MDAwMDAwWhcNMTcwNDA1MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAL/GlaryvhrL+eLYe+8Pv6D/sITLb5c2D5oaq6drPbcqP06xnyLgeFlIwzshIHi5+/Ib
fwSSXRzCDihXBfPlbv2Yf7C0F7QwUYNnqvxfnIZvu/6YFXkWt6Z5h5wvnbFmHWZBiBM8cEMP
qdT7myXDKuHSYvpiCFnIAHJOeoyBRV1I8kyupPe9aBkcYmwAyMjMRgeR92iV4TfTSx4CMRax
OHwa+WUAc2mjWiZOxyxTByORzm2wB2izX/DoeSwcN9mliRAZQ3eBXQD/HoO0LBIX3MXCp9Ry
wHIhz+Qy3mR0VgUu2gGu1r0lLIGwxKE4kEO1I7aBf5hQK/wVKcMyMMpNnU0CAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSCdqr1QGt7
r/f9VkCCmYSI3t5aDjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAFClbz5g+/TKUP9zpmoRdZymgYrU
fgq1UlnzLcgI3IH46LaMMMzUCRn7tz8OM2igQEqpSW9u80W3jaYsRLUdySvE6Jxr9xVPVDGu
JMAenNDS3sgNsKvUcCIeQYYTG4/oYTcuV6jtXTSDK0Y8NQ0pNEg8BnQz3V+nPXYC3/CWoFQ+
4InVPLGTZedK+yev6ee6wWWL3neskkSsYpwW1qTWtjHQcNw2eBphxRq5aNM9F3wKGdkUHKUJ
4mof2ckALH5SO/n0GGR58cgrtfuD/fcqvfsTtiMCHk6oW2ZE5Ty93aDvEhYo5RrA0TpFGoOA
m33FY3lP8EGzGel61qKU5nDH1hUxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBvIAvByRn0gXptBJbNZg3jMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjA4MDUwNjA5MDhaMC8GCSqGSIb3DQEJBDEiBCBUj8o7DuazIX5azKbcB0Mxe72UcmKD
DN+X2AgzHPen+zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQbyALwckZ9IF6bQSWzWYN4zANBgkqhkiG9w0BAQEFAASCAQADsQL4+VWP
yJJtasWJqHEBTIh4IAFAbRL2Z5FCD3Ocs00EATfv04KJBt1/As3Gg6HliAtyXCseqnwCXSa2
o7z1T82gwp0yJMX5NsTge2uzFRipx+4WMwgrOns8uzD0IYbRoWzSikd7wd2GEHid5y8DHF7K
8yGZSJ2Yv2YKhk0HHAI8tvD61M+E/zKiuKWwKA5LPSokky02Y+ONJ/6CmgaF2E44omV5thfp
4YKFAad4R+G9TDRyWJCC2H9Tyb5rw0PiWkQFBiB4Yh5o11WZvHO67Y0HSPna2XcDVnm6k5ab
2KyjI4cqnKKJWrbGjn1UtU6Sa+z5DkDSnRCPFHFwq7VUAAAAAAAA
--------------ms010405010608000707020007--


From nobody Fri Aug  5 02:19:00 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD6512D831 for ; Fri,  5 Aug 2016 02:18:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 K3GbtGBZiPdG for ; Fri,  5 Aug 2016 02:18:57 -0700 (PDT)
Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4476912D0F1 for ; Fri,  5 Aug 2016 02:18:57 -0700 (PDT)
Received: from nriea02.index.or.jp (unknown [172.19.246.37]) by nrifs03.index.or.jp (Postfix) with SMTP id 905FF17EB08; Fri,  5 Aug 2016 18:18:56 +0900 (JST)
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea02.index.or.jp (unknown) with ESMTP id u759IuD2015748; Fri, 5 Aug 2016 18:18:56 +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 u759Iusq012280; Fri, 5 Aug 2016 18:18:56 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u759IuDa012279; Fri, 5 Aug 2016 18:18:56 +0900
X-Authentication-Warning: nrims00b.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 nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u759IuKN012276; Fri, 5 Aug 2016 18:18:56 +0900
From: "Nat Sakimura" 
To: "'Vladimir Dzhuvinov'" , 
References: <20160804035457.9671.15892.idtracker@ietfa.amsl.com> <102ec164-bc1a-cc35-820b-fa9ceb237b1c@connect2id.com> <02cf01d1ee3f$65c8e4f0$315aaed0$@nri.co.jp> 
In-Reply-To: 
Date: Fri, 5 Aug 2016 18:19:08 +0900
Message-ID: <000d01d1eefa$6b6c0110$42440330$@nri.co.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQKWRHCz9KilBlvCi+NGwnZspa1BqQEXSYAEApAnd2ECWJlacZ6BXwoQ
Content-Language: ja
X-MailAdviser: 20141126
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.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, 05 Aug 2016 09:19:00 -0000

Hi Vladimir, 

See inline: 



> -----Original Message-----
> From: Vladimir Dzhuvinov [mailto:vladimir@connect2id.com]
> Sent: Friday, August 5, 2016 5:15 AM
> To: Nat Sakimura ; oauth@ietf.org
> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt
> 
> Hi Nat,
> 
> 
> On 04/08/16 14:00, Nat Sakimura wrote:
> >
> >> 1. alg:none request JWTs being no longer permitted
> >
> > I think it is a bug of the OpenID Connect Core 1.0.
> > Request Object itself can be alg=none in OAuth JAR draft 08 as well.
> > If alg=none, it MUST NOT be passed by value using `request` parameter.
> > It is fine to be that way as long as you pass it by reference.
> >
> > Like OAuth JAR draft-08, OpenID Connect used to have a section dedicated
> > to "Request Object" if I remember correctly. However, during the
> > re-factoring,
> > it was subsumed in "5.5.  Requesting Claims using the "claims" Request
> > Parameter" and the statement about allowing alg=none in Request Object
> > that are passed by value sneaked in there.
> > I am going to file a bug report for OpenID Connect on this.
> >
> > Or, do you have any specific use case for keeping "alg=none" for the
> > "passing by value" case?
> 
> An "alg:none" request object has no value if it's passed by value, so
> yes, in that sense we can call it a bug.
> 
> The only potential use case I see for "alg:none" is clients that can't
> handle crypto but may be able to pass the JWT via a HTTPS URL (perhaps
> preregistered).
> 
> 
> BTW, I don't see request URI registration mentioned, and this is quite a
> significant feature, especially in dynamic scenarios.
> 

It is obscure, I agree. The scenario was there from the beginning, 
and I made sure that it is permissible from the very beginning. 
The following sentences in 5.2.1 is talking about this. 

```
The Client stores the Request Object resource either locally or
remotely at a URL the Authorization Server can access.
```

Then, in Section 10.3, it goes: 

```
(c)  Authorization Server is providing an endpoint that provides a
        Request Object URI in exchange for a Request Object.
  [...snip...]

(d)  A third party, such as a Trust Framework Provider, provides an
        endpoint that provides a Request Object URI in exchange for a
        Request Object.
```

BTW, I found a bug in 10.3. (d). The reference (b) in 
the paragraph 1 should be (c) instead. 

Perhaps I should mention these possibilities in the Intro and 
5.2. 

More significant change would be to define an API to do it, e.g., 

swagger: '2.0'
info:
  version: "1.0.0"
  title: Request Registration Endpoint Example
  description: |
    An example for how to use Request Registration Endpoint.
host: as.example.com
schemes:
  - https
securityDefinitions:
  basicAuth:
    type: basic
    description: HTTP Basic Authentication. Works over `HTTPS`
paths:
  /v1/requestObjects/:
    post:
      security:
       - basicAuth: []
      responses:
        200:
          description:  Request Uri
          schema: 
            $ref: #/definitions/RequestURIResponse
          examples: 
            application/json: |-
              {
                "request_uri": "file://mc.example.com/aFwfo9w",
              }
        default:
          description: Unexpected Error
          schema:
            $ref: "#/definitions/Error"

Though it is possible to define something like this in this spec., 
I would rather do it as a separate spec. 
> 
> >
> >> 2. HTTPS request_uri's becoming always required, though there is
> confusion
> > about that (see below).
> >
> >
> >
> > I should remove the statement in 5.2.1., as it just meant to have
repeated
> > what it was said in 5.2.
> >
> >
> I see.
> 
> > I should also add further condition in 5.2. so that it becomes:
> > ```
> > unless the target Request Object is signed in a way that is
> > verifiable by the Authorization Server and the channel is
> > protected so that network attacker cannot observe.
> > ```
> > What do you think?
> On the 1st condition - HMAC - protected or signed request object to
> ensure authenticity - ok, this is a must if the JWT is fed via plain
> HTTP, to ensure the parameters cannot be tampered with.
> 
> On the 2nd condition - do you mean encrypting the JWT, 
> or something else?

For example, the Authorization Server (AS) may provide 
a Request Object registration service which returns 
a HTTP `request_uri` which is only accessible by the AS. 

> >
> >
> > 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.
> >
> >
> >
> > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir
> Dzhuvinov
> > Sent: Thursday, August 4, 2016 6:59 PM
> > To: oauth@ietf.org
> > Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-08.txt
> >
> >
> >
> > Thanks Nat.
> >
> > It looks like draft-ietf-oauth-jwsreq-08.txt is breaking with OpenID
> Connect
> > in regard to
> >
> > 1. alg:none request JWTs being no longer permitted
> >
> > 2. HTTPS request_uri's becoming always required, though there is
confusion
> > about that (see below).
> >
> >
> >
> > I don't know if this is intentional.
> >
> >
> >
> > Quoting the original Connect spec on alg:none:
> >
> > http://openid.net/specs/openid-connect-core-1_0.html#RequestObject
> >
> > ```
> > The Request Object MAY be signed or unsigned (plaintext). When it is
> > plaintext, this is indicated by use of the none algorithm
> >  [JWA] in
> the JOSE
> > Header.
> > ```
> >
> >
> > There is also confusion about the requirement to have HTTPS, which in
> 5.2 is
> > conditionally required, and in 5.2.1 always required (the 5.2.1 edit
> > appeared in -08).
> >
> > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2
> >
> > ```
> >
> > The contents of the resource referenced by the URL MUST be a Request
> > Object.  The scheme used in the "request_uri" value MUST be "https",
> > unless the target Request Object is signed in a way that is
> > verifiable by the Authorization Server.
> > ```
> >
> >
> > https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-08#section-5.2.1
> >
> > ```
> >
> > The URL MUST be HTTPS URL.
> >
> > ```
> >
> >
> > Cheers,
> >
> > Vladimir
> >
> >
> 
> --
> Vladimir Dzhuvinov :: vladimir@connect2id.com
> 
--
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.



From nobody Fri Aug  5 03:17:07 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE5212D686 for ; Fri,  5 Aug 2016 03:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NT96HdfHOklk for ; Fri,  5 Aug 2016 03:17:01 -0700 (PDT)
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 3C26112B074 for ; Fri,  5 Aug 2016 03:17:01 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id w38so171962575qtb.0 for ; Fri, 05 Aug 2016 03:17:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mbn7PD5i4ZOi4pbskV2QSdbFCaKuiR/YZej41qY3ZFk=; b=eVRl0Yv7Hc7s1Lr1/cY1zlQeAJWmk85GdXRIwmYttGGHc7tu5CMTdaFroiP7iUo2dp XefyjL+GZIzoK34WM4yHy6bceBJS7LpAcG5vrxoXFB053Tt+4B+wg2Ja/BmYHSpWl9C3 yil61K+tnl3nKFsXQsVV9HddRIeJco8zQJ9tBa3Rwn+vM4iqHymTymyXinwfmWkPckz9 nNAuJYpVpqEKOFDx41AwRI2xiULeghLkUacMX0HN5/wCecWVA6iRJcGygnLCcjkb1S4d fc45qIgOcxCEky68XCZ9TY+gi9I3mlSvv35adqSqoam21duAAGiJ3OcF+vp/9JuvR8ii BQnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mbn7PD5i4ZOi4pbskV2QSdbFCaKuiR/YZej41qY3ZFk=; b=iVKVv6vhQH/CjF1Es0zbXqLLqnAFjpSsr83CCeERC4ehTKZbF3qYf1KiLiIg5MYu50 uqpjLTlHUvoAFN25V2lsnZnXfFo07zYlQlYYeh2xaVu79IOEtZZuTpzXiHgF78fHbQsz n9puVY4lgnP+sgUi8wgBHXPbQhiZuGVo62QJUn50itpyK6lirl8At/xY8k2iBhYQyiX0 3M4/wsIuDZ9XCThE18gcAHHh93uN3gFrp6ZTjRGfJ/C11BThPPXFD/kJKbC9UZu5jpfr TihUU1F6mlyEB7oNLkw6GzWOw26LFTPNLKHuj2iBlYYkt9Rn3nIbd2qa0a6M6jDeP+ul XesQ==
X-Gm-Message-State: AEkoousm8jYIpUt53svDYqREccq0f4UMUaSA3wqRsFzqpMM1ZC0Hcg8IA7zj1ONy9i3inMHuY1FtJcobsyz1LA==
X-Received: by 10.237.59.212 with SMTP id s20mr11489868qte.126.1470392220303;  Fri, 05 Aug 2016 03:17:00 -0700 (PDT)
MIME-Version: 1.0
References:   <8F94CB33-41A6-438E-BE15-38A90FE653F5@oracle.com> <6a1e6f1e-16a3-c150-e057-a28a7d5b2b33@gmail.com> <5E317DFF-AE9B-4D18-9281-3C349AB57357@ve7jtb.com>  <7DE586FF-3450-4664-8CBC-85632B87A54D@ve7jtb.com>
In-Reply-To: <7DE586FF-3450-4664-8CBC-85632B87A54D@ve7jtb.com>
From: Nat Sakimura 
Date: Fri, 05 Aug 2016 10:16:49 +0000
Message-ID: 
To: John Bradley , Sergey Beryozkin 
Content-Type: multipart/alternative; boundary=94eb2c190c30f8c6ac0539505d73
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using IdToken instead of Access token
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, 05 Aug 2016 10:17:05 -0000

--94eb2c190c30f8c6ac0539505d73
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I can sort of understand why people would want to do it, and there are
legitimate cases.

This is the case where the RS is in fact an AS (ASr)  in that resource
domain and the RS is dependent on the federated AS (ASf) for the
authentication. In such a case, the ASf cannot really make the access
decision.
It is the ASr that makes the decision based on the user authentication
results, and possibly the authorisation result at ASf combined. To the ASf,
the 'client' is the combination of the app that the user is using and the
RS. So, the app sends the ID Token to the RS=3DASr. This pattern is perfect=
ly
legitimate as long as the RS is also in the audience.

Best,

Nat

2016=E5=B9=B48=E6=9C=885=E6=97=A5(=E9=87=91) 5:58 John Bradley :

> The token exchange spec allows for the token issued to have claims about
> the subject of the input token.   This is what we generally think about a=
s
> impersonation.
> That is really the same as a normal OAuth access token for the most part.
>
> You can also ask for a composite token that contains claims about the
> presenter and the original subject.   This allows for the auditing of who
> is making the request for the subject.
>
> This sort of composite token was introduced in WS-Trust 1.4 and is called
> ActAs in that spec and we refer to as delegation.
>
> This is desired when a RS (A) receives a access token and then needs to
> become a client (A) to access another service in the context of the acces=
s
> token.
>
> The second RS (B) is protected and can=E2=80=99t be access directly by th=
e the
> original OAuth client.  The client (A) needs a new access token based on
> its client credential plus the original access token to get a token that =
RS
> (B)  will accept.   RS (B) also wants to know who the client that is
> accessing it for audit or other reasons.
>
> That is one of the things that the new delegated token type is for.  The
> impersonation type is basically the same sort of impersonation type token
> that we use now.
>
> I admit that OAuth is vague about delegation vs impersonation and they ar=
e
> generally left as implementation decisions as the tokens are considered
> opaque.
>
> For token exchange we wanted to be more explicit so that the client has
> more control over the exchange.
>
> I hope that helps.
>
> John B.
>
> > On Aug 4, 2016, at 12:26 PM, Sergey Beryozkin 
> wrote:
> >
> > Hi John
> >
> > I think it is closer to what I'm trying to understand :-). Let me work
> with the text below, I'll likely have few more questions to follow later =
on
> >
> > Thanks, Sergey
> >
> > On 04/08/16 17:04, John Bradley wrote:
> >> The id_token and access token have different semantics, and quite
> possable possibly formats.
> >>
> >> So the AT that comes with the id_token will be useful at RS associated
> with the AS, but it may not be useful at other API the client wants to
> access and that is generally where we run into the use case for token
> exchange.
> >>
> >> In the case of talking to a third party API it may be useful to have
> that API have a token exchange endpoint where a client can exchange a
> id_token/JWT for an access token.
> >> That is clearer and likely more secure given a confidential client
> than just using the id_token as a access token directly.
> >>
> >> Now I do understand people do that now.
> >>
> >> In the hopefully near future once we have token binding as a proof of
> possession mechanism it will be come clearer that you cant take a id_toke=
n
> that is bound to the browser presenting the token to the client and
> directly re use that as a secure access token.   The AT and RT issued wit=
h
> that token will be bound to the client so that the RS can validate them.
> >>
> >> There are a lot of bad patterns possible with bearer tokens.   I prefe=
r
> to try to avoid them so that people will be in a better position when we
> move off bearer tokens for increased security.
> >>
> >> John B.
> >>> On Aug 4, 2016, at 11:17 AM, Sergey Beryozkin 
> wrote:
> >>>
> >>> Hi Phil
> >>>
> >>> On 04/08/16 15:01, Phil Hunt (IDM) wrote:
> >>>> You might be munging two different flows with different semantics
> together.
> >>>>
> >>>> First flow is use oidc to authen the user to the client.
> >>>>
> >>>> Second flow is normal oauth authorization to get an at to access the
> resource.
> >>>>
> >>>> Often the OP AS is different from the RS's AS and the rs needs a
> proper "delegation" access token.
> >>> Indeed, this is more or less what I've been saying in our private
> discussions.
> >>>
> >>> But as I said to in my response to Mike, I see a demand to have
> IdToken propagated and given the token exchange draft has a dedicated
> 'impersonation' section I'm assuming there's a need for it.
> >>>
> >>> For example, I was checking the archives, could see Brian Campbell
> quoting Vittorio Bertocci:
> >>> "To summarize our main use case: we use [a token exchange like
> protocol] for achieving user impersonation thru tiers, or delegation for
> confidential clients which do not have any web UX..."
> >>>
> >>> The former case there suggests that if a client has a web UI they
> authenticate the user first and then start impersonating.
> >>>
> >>> I'm advocating for the clients to use the access tokens. The clients
> can requests the extra scopes while authenticating the user and if the us=
er
> approves these scopes the client can continue using AT on behalf of the
> client, and using IdToken to only interact with the user.
> >>>
> >>> But I'm finding it difficult to explain (show a clear differentiator)
> when the client should use AT and when they should use IdToken to
> impersonate a user and get a new token (via the token exchange)...
> >>>
> >>> Sergey
> >>>>
> >>>> Phil
> >>>>
> >>>>> On Aug 4, 2016, at 6:00 AM, Mike Schwartz  wrote:
> >>>>>
> >>>>> Sergey,
> >>>>>
> >>>>> Since no one answered your question, let me pose a few questions to
> your questions!
> >>>>>
> >>>>> Wouldn't it give you more flexibility to issue a different token to
> >>>>> represent access to the RS API? In terms of passing user claims,
> >>>>> couldn't this be done via parameters in the API? Are you trying to =
do
> >>>>> more with OpenID Connect than was anticpiated in the design?
> >>>>> The id_token has an audience, are you including more than one clien=
t
> in that
> >>>>> audience? Would it make sense to look at token exchange and
> downscope the token?
> >>>>> If you are looking for a profile of OAuth2, might UMA work?
> >>>>>
> >>>>> I think you're not alone in wondering what the answer to all these
> questions are..
> >>>>>
> >>>>> - Mike
> >>>>>
> >>>>>
> >>>>> -------------------------------------
> >>>>> Michael Schwartz
> >>>>> Gluu
> >>>>> http://gluu.org
> >>>>>
> >>>>>> Message: 3
> >>>>>> Date: Wed, 3 Aug 2016 11:08:29 +0100
> >>>>>> From: Sergey Beryozkin 
> >>>>>> To: "oauth@ietf.org" 
> >>>>>> Subject: [OAUTH-WG] Using IdToken instead of Access token
> >>>>>> Message-ID: 
> >>>>>> Content-Type: text/plain; charset=3Dwindows-1252; format=3Dflowed
> >>>>>> Hi All
> >>>>>> I hope this question is better suited for this list. Will have no
> >>>>>> problems redirecting it to the openid-connect list instead.
> >>>>>> Consider a user working with the client web application (OIDC RP)
> which
> >>>>>> authenticates the user with the OIDC authorization code flow at th=
e
> end
> >>>>>> of which the client gets AccessToken + IdToken. Next the user
> requests
> >>>>>> something from the client which needs to access the RS to complete
> this
> >>>>>> request.
> >>>>>> And the idea is to have the client pass IdToken to RS and use
> various
> >>>>>> user claims inside this IdToken to enforce the access control at
> the RS
> >>>>>> level. My position it is likely wrong but I guess I may be missing
> >>>>>> something that will be either in favor or against it.
> >>>>>> The reason I think it is wrong is that if the client is using a co=
de
> >>>>>> flow then the right approach for staying within the OAuth2 'world'
> is to
> >>>>>> use the access token to talk to RS and use IdToken only for the
> purpose
> >>>>>> of interacting with the user. The access token represents a proper
> user
> >>>>>> authorization and can have the extra scopes in addition to "oidc"
> which
> >>>>>> RS can depend upon in its access control restrictions.
> >>>>>> Next I'm arguing that if the IdToken is used instead then it is th=
e
> case
> >>>>>> of the client impersonating the user. And refer to the STS for the
> REST
> >>>>>> of Us draft (I have a separate series of question on that draft).
> I'm
> >>>>>> saying the impersonation can work but ignoring the access tokens
> >>>>>> completely will make the overall solution much less flexible.
> >>>>>> I'd like to ask for some advice/guidance:
> >>>>>> - Is it a good idea at all for the client to use IdToken instead o=
f
> >>>>>> AccessToken as explored above ? I suppose it can work, in the code
> flow
> >>>>>> the client gets the access token which, by default, only allows to
> >>>>>> access UserInfo. Perhaps the client impersonating IdToken for the
> >>>>>> purpose of accessing RS is not too bad after all.
> >>>>>> - Assuming the impersonation is OK, what is the right criteria for
> the
> >>>>>> client to choose to work with IdToken instead of the access token
> when
> >>>>>> accessing the immediate RS. It seems like if the impersonation is
> OK for
> >>>>>> the client to do then why have access tokens at all...
> >>>>>> - Assuming the impersonation is OK, does STS For the REST of Us
> shows
> >>>>>> the right and the only way it needs to be done ? I can imagine how
> it
> >>>>>> will work for the web app clients, but what about Implicit Clients=
.
> >>>>>> Many thanks, Sergey
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>>
> >>>
> >>>
> >>> --
> >>> Sergey Beryozkin
> >>>
> >>> Talend Community Coders
> >>> http://coders.talend.com/
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >
> >
> > --
> > Sergey Beryozkin
> >
> > Talend Community Coders
> > http://coders.talend.com/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--=20

Nat Sakimura

Chairman of the Board, OpenID Foundation

--94eb2c190c30f8c6ac0539505d73
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I can sort of understand why people would want to do it, and=
 there are legitimate cases. 


This is the case where the RS is in fact an AS (ASr)=C2=A0 i=
n that resource domain and the RS is dependent on the federated AS (ASf) fo=
r the authentication. In such a case, the ASf cannot really make the access=
 decision. 

It is the ASr that makes the decision based on the user authentication resu=
lts, and possibly the authorisation result at ASf combined. To the ASf, the=
 'client' is the combination of the app that the user is using and =
the RS. So, the app sends the ID Token to the RS=3DASr. This pattern is per=
fectly legitimate as long as the RS is also in the audience. 


Best, 


Nat 




2016=E5=B9=B48=E6=9C=885=E6=
=97=A5(=E9=87=91) 5:58 John Bradley <ve7jtb@ve7jtb.com>:
The to=
ken exchange spec allows for the token issued to have claims about the subj=
ect of the input token.=C2=A0 =C2=A0This is what we generally think about a=
s impersonation.

That is really the same as a normal OAuth access token for the most part.


You can also ask for a composite token that contains claims about the prese=
nter and the original subject.=C2=A0 =C2=A0This allows for the auditing of =
who is making the request for the subject.



This sort of composite token was introduced in WS-Trust 1.4 and is called A=
ctAs in that spec and we refer to as delegation.



This is desired when a RS (A) receives a access token and then needs to bec=
ome a client (A) to access another service in the context of the access tok=
en.



The second RS (B) is protected and can=E2=80=99t be access directly by the =
the original OAuth client.=C2=A0 The client (A) needs a new access token ba=
sed on its client credential plus the original access token to get a token =
that RS (B)=C2=A0 will accept.=C2=A0 =C2=A0RS (B) also wants to know who th=
e client that is accessing it for audit or other reasons.



That is one of the things that the new delegated token type is for.=C2=A0 T=
he impersonation type is basically the same sort of impersonation type toke=
n that we use now.



I admit that OAuth is vague about delegation vs impersonation and they are =
generally left as implementation decisions as the tokens are considered opa=
que.



For token exchange we wanted to be more explicit so that the client has mor=
e control over the exchange.



I hope that helps.



John B.



> On Aug 4, 2016, at 12:26 PM, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
>

> Hi John

>

> I think it is closer to what I'm trying to understand :-). Let me =
work with the text below, I'll likely have few more questions to follow=
 later on

>

> Thanks, Sergey

>

> On 04/08/16 17:04, John Bradley wrote:

>> The id_token and access token have different semantics, and quite =
possable possibly formats.

>>

>> So the AT that comes with the id_token will be useful at RS associ=
ated with the AS, but it may not be useful at other API the client wants to=
 access and that is generally where we run into the use case for token exch=
ange.

>>

>> In the case of talking to a third party API it may be useful to ha=
ve that API have a token exchange endpoint where a client can exchange a id=
_token/JWT for an access token.

>> That is clearer and likely more secure given a confidential client=
=C2=A0 than just using the id_token as a access token directly.

>>

>> Now I do understand people do that now.

>>

>> In the hopefully near future once we have token binding as a proof=
 of possession mechanism it will be come clearer that you cant take a id_to=
ken that is bound to the browser presenting the token to the client and dir=
ectly re use that as a secure access token.=C2=A0 =C2=A0The AT and RT issue=
d with that token will be bound to the client so that the RS can validate t=
hem.

>>

>> There are a lot of bad patterns possible with bearer tokens.=C2=A0=
 =C2=A0I prefer to try to avoid them so that people will be in a better pos=
ition when we move off bearer tokens for increased security.

>>

>> John B.

>>> On Aug 4, 2016, at 11:17 AM, Sergey Beryozkin <sberyozkin@gmail.com> =
wrote:

>>>

>>> Hi Phil

>>>

>>> On 04/08/16 15:01, Phil Hunt (IDM) wrote:

>>>> You might be munging two different flows with different se=
mantics together.

>>>>

>>>> First flow is use oidc to authen the user to the client.
>>>>

>>>> Second flow is normal oauth authorization to get an at to =
access the resource.

>>>>

>>>> Often the OP AS is different from the RS's AS and the =
rs needs a proper "delegation" access token.

>>> Indeed, this is more or less what I've been saying in our =
private discussions.

>>>

>>> But as I said to in my response to Mike, I see a demand to hav=
e IdToken propagated and given the token exchange draft has a dedicated =
9;impersonation' section I'm assuming there's a need for it.
>>>

>>> For example, I was checking the archives, could see Brian Camp=
bell quoting Vittorio Bertocci:

>>> "To summarize our main use case: we use [a token exchange=
 like protocol] for achieving user impersonation thru tiers, or delegation =
for confidential clients which do not have any web UX..."

>>>

>>> The former case there suggests that if a client has a web UI t=
hey authenticate the user first and then start impersonating.

>>>

>>> I'm advocating for the clients to use the access tokens. T=
he clients can requests the extra scopes while authenticating the user and =
if the user approves these scopes the client can continue using AT on behal=
f of the client, and using IdToken to only interact with the user.

>>>

>>> But I'm finding it difficult to explain (show a clear diff=
erentiator) when the client should use AT and when they should use IdToken =
to impersonate a user and get a new token (via the token exchange)...

>>>

>>> Sergey

>>>>

>>>> Phil

>>>>

>>>>> On Aug 4, 2016, at 6:00 AM, Mike Schwartz <mike@gluu.org> wrote:
>>>>>

>>>>> Sergey,

>>>>>

>>>>> Since no one answered your question, let me pose a few=
 questions to your questions!

>>>>>

>>>>> Wouldn't it give you more flexibility to issue a d=
ifferent token to

>>>>> represent access to the RS API? In terms of passing us=
er claims,

>>>>> couldn't this be done via parameters in the API? A=
re you trying to do

>>>>> more with OpenID Connect than was anticpiated in the d=
esign?

>>>>> The id_token has an audience, are you including more t=
han one client in that

>>>>> audience? Would it make sense to look at token exchang=
e and downscope the token?

>>>>> If you are looking for a profile of OAuth2, might UMA =
work?

>>>>>

>>>>> I think you're not alone in wondering what the ans=
wer to all these questions are..

>>>>>

>>>>> - Mike

>>>>>

>>>>>

>>>>> -------------------------------------

>>>>> Michael Schwartz

>>>>> Gluu

>>>>> http://gluu.org

>>>>>

>>>>>> Message: 3

>>>>>> Date: Wed, 3 Aug 2016 11:08:29 +0100

>>>>>> From: Sergey Beryozkin <sberyozkin@gmail.com>

>>>>>> To: "oauth@ietf.org" <oauth@ietf.org>

>>>>>> Subject: [OAUTH-WG] Using IdToken instead of Acces=
s token

>>>>>> Message-ID: <b026f4fc-3e08-4e00-02c3-8=
4be2dc4b2bb@gmail.com>

>>>>>> Content-Type: text/plain; charset=3Dwindows-1252; =
format=3Dflowed

>>>>>> Hi All

>>>>>> I hope this question is better suited for this lis=
t. Will have no

>>>>>> problems redirecting it to the openid-connect list=
 instead.

>>>>>> Consider a user working with the client web applic=
ation (OIDC RP) which

>>>>>> authenticates the user with the OIDC authorization=
 code flow at the end

>>>>>> of which the client gets AccessToken + IdToken. Ne=
xt the user requests

>>>>>> something from the client which needs to access th=
e RS to complete this

>>>>>> request.

>>>>>> And the idea is to have the client pass IdToken to=
 RS and use various

>>>>>> user claims inside this IdToken to enforce the acc=
ess control at the RS

>>>>>> level. My position it is likely wrong but I guess =
I may be missing

>>>>>> something that will be either in favor or against =
it.

>>>>>> The reason I think it is wrong is that if the clie=
nt is using a code

>>>>>> flow then the right approach for staying within th=
e OAuth2 'world' is to

>>>>>> use the access token to talk to RS and use IdToken=
 only for the purpose

>>>>>> of interacting with the user. The access token rep=
resents a proper user

>>>>>> authorization and can have the extra scopes in add=
ition to "oidc" which

>>>>>> RS can depend upon in its access control restricti=
ons.

>>>>>> Next I'm arguing that if the IdToken is used i=
nstead then it is the case

>>>>>> of the client impersonating the user. And refer to=
 the STS for the REST

>>>>>> of Us draft (I have a separate series of question =
on that draft). I'm

>>>>>> saying the impersonation can work but ignoring the=
 access tokens

>>>>>> completely will make the overall solution much les=
s flexible.

>>>>>> I'd like to ask for some advice/guidance:

>>>>>> - Is it a good idea at all for the client to use I=
dToken instead of

>>>>>> AccessToken as explored above ? I suppose it can w=
ork, in the code flow

>>>>>> the client gets the access token which, by default=
, only allows to

>>>>>> access UserInfo. Perhaps the client impersonating =
IdToken for the

>>>>>> purpose of accessing RS is not too bad after all.<=
br>
>>>>>> - Assuming the impersonation is OK, what is the ri=
ght criteria for the

>>>>>> client to choose to work with IdToken instead of t=
he access token when

>>>>>> accessing the immediate RS. It seems like if the i=
mpersonation is OK for

>>>>>> the client to do then why have access tokens at al=
l...

>>>>>> - Assuming the impersonation is OK, does STS For t=
he REST of Us shows

>>>>>> the right and the only way it needs to be done ? I=
 can imagine how it

>>>>>> will work for the web app clients, but what about =
Implicit Clients.

>>>>>> Many thanks, Sergey

>>>>>

>>>>> _______________________________________________

>>>>> OAuth mailing list

>>>>> OA=
uth@ietf.org

>>>>> https://www.ietf.org/mailman/listinf=
o/oauth

>>>>

>>>> _______________________________________________

>>>> OAuth mailing list

>>>> OAuth@=
ietf.org

>>>> https://www.ietf.org/mailman/listinfo/oa=
uth

>>>>

>>>

>>>

>>> --

>>> Sergey Beryozkin

>>>

>>> Talend Community Coders

>>> http://coders.talend.com/

>>>

>>> _______________________________________________

>>> OAuth mailing list

>>> OAuth@ietf=
.org

>>> https://www.ietf.org/mailman/listinfo/oauth<=
/a>

>>

>

>

> --

> Sergey Beryozkin

>

> Talend Community Coders

> http://coders.talend.com/



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth


-- 
Nat Sakimura


Chairman of the Board, OpenID Foundation




--94eb2c190c30f8c6ac0539505d73--


From nobody Fri Aug  5 04:14:19 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D0B12D10B for ; Fri,  5 Aug 2016 04:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 cR9evx_x3LAe for ; Fri,  5 Aug 2016 04:14:15 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC17C128E18 for ; Fri,  5 Aug 2016 04:14:14 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id f65so27317582wmi.0 for ; Fri, 05 Aug 2016 04:14:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=KDkyP+5O0kDg6tV2XQbqMyFmyMHWlP1viJ17QeLJwv8=; b=ojYgW32J6P2NLR73JUkgwsVqATnj3bD8UUWPlxzeU/u/3KqBmWDt1M3NidIaYx/kpT Cj2VE6Ux5AuhVrE9MMq9WXpj2syKKxcJ7YpzfUG7YdCk09Fy+Y6lvixev8mW+cev08jC 5btLoLAJaphJy0Nxl3HxnQIvS1QjLOR/dtLopHts3lwFC37lQT/0QO5oe38Ivoq6icIo ZWAywjvwLWnnQqoXEhQdrBJ0CxLVcL6o08XiDIa1mbc9p6vUoIHLFAcX4nkFmS8wRZyD /uFLHd6+2XLEuogF0JVFRzh0GWEr2lTTups+rs2bpN95pNKCtDbYVRyDFhl9fWd6G5po Px9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KDkyP+5O0kDg6tV2XQbqMyFmyMHWlP1viJ17QeLJwv8=; b=L19Nd4xRv9Qhy/R3WxoB2kMoVoQWWcdl2v0DI9c9v+KeuZ89GieMLLKl2w0vUldEs+ a8V1Z/5gPcdGKEhEmJDyxk5AEuQv3nkvGDOzykdUgoAev/XvIhgxP1m+h/Uaua+ikl2K hLZQU6oVj/MoczC0ieLD/jTzmfH3Z0Zv2UqowOuOxlGufxTXk3fr+hXeGTtUradBufNJ M2nfdlSi+hPBbbkEDDQCjlc/V4JHvke9wPa5cDzHKjqrBdMV8GCp4YLA8LPhReUJBJNw p7LRHE4P7Spw84l8qhx+Z3bNgWTPyWk2cdffRe9/AE8t51nYTsuotNMI+T6emMLreLRe 4L2g==
X-Gm-Message-State: AEkoouu/Z3VE6zm3DVLTm+qXVGwU9EDhSh4IDv+43IssYOAS8+M75YQsbng3iE8g0gVzxA==
X-Received: by 10.194.32.195 with SMTP id l3mr70104308wji.27.1470395653101; Fri, 05 Aug 2016 04:14:13 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id kq2sm17317956wjc.41.2016.08.05.04.14.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2016 04:14:12 -0700 (PDT)
To: John Bradley 
References:   <8F94CB33-41A6-438E-BE15-38A90FE653F5@oracle.com> <6a1e6f1e-16a3-c150-e057-a28a7d5b2b33@gmail.com> <5E317DFF-AE9B-4D18-9281-3C349AB57357@ve7jtb.com>  <7DE586FF-3450-4664-8CBC-85632B87A54D@ve7jtb.com>
From: Sergey Beryozkin 
Message-ID: <8f6019f0-48a9-c1e3-5705-ac136debd868@gmail.com>
Date: Fri, 5 Aug 2016 12:14:11 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <7DE586FF-3450-4664-8CBC-85632B87A54D@ve7jtb.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using IdToken instead of Access token
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, 05 Aug 2016 11:14:18 -0000

Hi John

On 04/08/16 21:58, John Bradley wrote:
> The token exchange spec allows for the token issued to have claims about the subject of the input token.   This is what we generally think about as impersonation.
> That is really the same as a normal OAuth access token for the most part.
>
> You can also ask for a composite token that contains claims about the presenter and the original subject.   This allows for the auditing of who is making the request for the subject.
>
> This sort of composite token was introduced in WS-Trust 1.4 and is called ActAs in that spec and we refer to as delegation.
>
> This is desired when a RS (A) receives a access token and then needs to become a client (A) to access another service in the context of the access token.
>
> The second RS (B) is protected and can’t be access directly by the the original OAuth client.  The client (A) needs a new access token based on its client credential plus the original access token to get a token that RS (B)  will accept.   RS (B) also wants to know who the client that is accessing it for audit or other reasons.
>
> That is one of the things that the new delegated token type is for.  The impersonation type is basically the same sort of impersonation type token that we use now.
>
> I admit that OAuth is vague about delegation vs impersonation and they are generally left as implementation decisions as the tokens are considered opaque.
>
> For token exchange we wanted to be more explicit so that the client has more control over the exchange.
>
> I hope that helps.

It does.
Cheers, Sergey

>
> John B.
>
>> On Aug 4, 2016, at 12:26 PM, Sergey Beryozkin  wrote:
>>
>> Hi John
>>
>> I think it is closer to what I'm trying to understand :-). Let me work with the text below, I'll likely have few more questions to follow later on
>>
>> Thanks, Sergey
>>
>> On 04/08/16 17:04, John Bradley wrote:
>>> The id_token and access token have different semantics, and quite possable possibly formats.
>>>
>>> So the AT that comes with the id_token will be useful at RS associated with the AS, but it may not be useful at other API the client wants to access and that is generally where we run into the use case for token exchange.
>>>
>>> In the case of talking to a third party API it may be useful to have that API have a token exchange endpoint where a client can exchange a id_token/JWT for an access token.
>>> That is clearer and likely more secure given a confidential client  than just using the id_token as a access token directly.
>>>
>>> Now I do understand people do that now.
>>>
>>> In the hopefully near future once we have token binding as a proof of possession mechanism it will be come clearer that you cant take a id_token that is bound to the browser presenting the token to the client and directly re use that as a secure access token.   The AT and RT issued with that token will be bound to the client so that the RS can validate them.
>>>
>>> There are a lot of bad patterns possible with bearer tokens.   I prefer to try to avoid them so that people will be in a better position when we move off bearer tokens for increased security.
>>>
>>> John B.
>>>> On Aug 4, 2016, at 11:17 AM, Sergey Beryozkin  wrote:
>>>>
>>>> Hi Phil
>>>>
>>>> On 04/08/16 15:01, Phil Hunt (IDM) wrote:
>>>>> You might be munging two different flows with different semantics together.
>>>>>
>>>>> First flow is use oidc to authen the user to the client.
>>>>>
>>>>> Second flow is normal oauth authorization to get an at to access the resource.
>>>>>
>>>>> Often the OP AS is different from the RS's AS and the rs needs a proper "delegation" access token.
>>>> Indeed, this is more or less what I've been saying in our private discussions.
>>>>
>>>> But as I said to in my response to Mike, I see a demand to have IdToken propagated and given the token exchange draft has a dedicated 'impersonation' section I'm assuming there's a need for it.
>>>>
>>>> For example, I was checking the archives, could see Brian Campbell quoting Vittorio Bertocci:
>>>> "To summarize our main use case: we use [a token exchange like protocol] for achieving user impersonation thru tiers, or delegation for confidential clients which do not have any web UX..."
>>>>
>>>> The former case there suggests that if a client has a web UI they authenticate the user first and then start impersonating.
>>>>
>>>> I'm advocating for the clients to use the access tokens. The clients can requests the extra scopes while authenticating the user and if the user approves these scopes the client can continue using AT on behalf of the client, and using IdToken to only interact with the user.
>>>>
>>>> But I'm finding it difficult to explain (show a clear differentiator) when the client should use AT and when they should use IdToken to impersonate a user and get a new token (via the token exchange)...
>>>>
>>>> Sergey
>>>>>
>>>>> Phil
>>>>>
>>>>>> On Aug 4, 2016, at 6:00 AM, Mike Schwartz  wrote:
>>>>>>
>>>>>> Sergey,
>>>>>>
>>>>>> Since no one answered your question, let me pose a few questions to your questions!
>>>>>>
>>>>>> Wouldn't it give you more flexibility to issue a different token to
>>>>>> represent access to the RS API? In terms of passing user claims,
>>>>>> couldn't this be done via parameters in the API? Are you trying to do
>>>>>> more with OpenID Connect than was anticpiated in the design?
>>>>>> The id_token has an audience, are you including more than one client in that
>>>>>> audience? Would it make sense to look at token exchange and downscope the token?
>>>>>> If you are looking for a profile of OAuth2, might UMA work?
>>>>>>
>>>>>> I think you're not alone in wondering what the answer to all these questions are..
>>>>>>
>>>>>> - Mike
>>>>>>
>>>>>>
>>>>>> -------------------------------------
>>>>>> Michael Schwartz
>>>>>> Gluu
>>>>>> http://gluu.org
>>>>>>
>>>>>>> Message: 3
>>>>>>> Date: Wed, 3 Aug 2016 11:08:29 +0100
>>>>>>> From: Sergey Beryozkin 
>>>>>>> To: "oauth@ietf.org" 
>>>>>>> Subject: [OAUTH-WG] Using IdToken instead of Access token
>>>>>>> Message-ID: 
>>>>>>> Content-Type: text/plain; charset=windows-1252; format=flowed
>>>>>>> Hi All
>>>>>>> I hope this question is better suited for this list. Will have no
>>>>>>> problems redirecting it to the openid-connect list instead.
>>>>>>> Consider a user working with the client web application (OIDC RP) which
>>>>>>> authenticates the user with the OIDC authorization code flow at the end
>>>>>>> of which the client gets AccessToken + IdToken. Next the user requests
>>>>>>> something from the client which needs to access the RS to complete this
>>>>>>> request.
>>>>>>> And the idea is to have the client pass IdToken to RS and use various
>>>>>>> user claims inside this IdToken to enforce the access control at the RS
>>>>>>> level. My position it is likely wrong but I guess I may be missing
>>>>>>> something that will be either in favor or against it.
>>>>>>> The reason I think it is wrong is that if the client is using a code
>>>>>>> flow then the right approach for staying within the OAuth2 'world' is to
>>>>>>> use the access token to talk to RS and use IdToken only for the purpose
>>>>>>> of interacting with the user. The access token represents a proper user
>>>>>>> authorization and can have the extra scopes in addition to "oidc" which
>>>>>>> RS can depend upon in its access control restrictions.
>>>>>>> Next I'm arguing that if the IdToken is used instead then it is the case
>>>>>>> of the client impersonating the user. And refer to the STS for the REST
>>>>>>> of Us draft (I have a separate series of question on that draft). I'm
>>>>>>> saying the impersonation can work but ignoring the access tokens
>>>>>>> completely will make the overall solution much less flexible.
>>>>>>> I'd like to ask for some advice/guidance:
>>>>>>> - Is it a good idea at all for the client to use IdToken instead of
>>>>>>> AccessToken as explored above ? I suppose it can work, in the code flow
>>>>>>> the client gets the access token which, by default, only allows to
>>>>>>> access UserInfo. Perhaps the client impersonating IdToken for the
>>>>>>> purpose of accessing RS is not too bad after all.
>>>>>>> - Assuming the impersonation is OK, what is the right criteria for the
>>>>>>> client to choose to work with IdToken instead of the access token when
>>>>>>> accessing the immediate RS. It seems like if the impersonation is OK for
>>>>>>> the client to do then why have access tokens at all...
>>>>>>> - Assuming the impersonation is OK, does STS For the REST of Us shows
>>>>>>> the right and the only way it needs to be done ? I can imagine how it
>>>>>>> will work for the web app clients, but what about Implicit Clients.
>>>>>>> Many thanks, Sergey
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>


From nobody Fri Aug  5 04:20:53 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB3912D72A for ; Fri,  5 Aug 2016 04:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 mgDzg2p4xzil for ; Fri,  5 Aug 2016 04:20:47 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c: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 767D612D0CB for ; Fri,  5 Aug 2016 04:20:46 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id o80so32287344wme.1 for ; Fri, 05 Aug 2016 04:20:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=3BTgpcjig6ti3grOehhZq9Y13Ztt5pNHgNd1PJQkOxg=; b=rQ9YDK0GeAcjiqw5q1BonS6jlbDFn010JR+5LcqVTjgfRDgIAIZfwAPdK+H4mMcJMi vOsYLwgcdn8hQSqvEf6R2VahkT5ZMvW0K0gZQbyw/PfkhHEypXQm88GgFKzOk9eesHty 4zKxQOEKZRfskLwF5PHtR5Sa2rnWeh/apVBmoPR8H04QZlB09VMdivk1y8d6f0d7pV/8 SoXuXJqR6jjC5APvVzWX0kUcAlSBcz2gN0u3zYlOd4WbVNW0XZGstjk1qtu1yt8TG958 TEg44hvOy6v6hd+/ezTK1JA+nwn4ARgWwwtMVILm3o9x7B3ywpozFMLdfTKE3wKfw+EX igxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3BTgpcjig6ti3grOehhZq9Y13Ztt5pNHgNd1PJQkOxg=; b=imOxLpRVJlmC3HK7s91YG2GTAeYpQbFhN3Cfz/sF3VK1Sz+RhCAnOmbRftCu9tkhd/ JWqsXNob196So/9TNIdcv42c5h8OzkAVlXg0PszoN2Wl/XcrhW0JfXP1gkTjilaq/Shs v3XARwwPdMmQ8/DRhjOZUkhsR/70KGE0KTDQIJTNVWtcwCKE91GZ4XmuhYuc3RLBMZCz KDRNIRbbFS19Mo8mGybGalOojMUFCRHkBsj/7ANbmuuuIM/kdAPvZneiz8GBmY0iF/Np PIE2Yyqd1dJ2vHYXf6blE31Irs+SMawBw3uDfAjFnqdQuurnnmLaZoDqm8CiWdZY78ES nijA==
X-Gm-Message-State: AEkoousIj6dc/54rLWdYI/KoUESxLAgDa0LMejwFIZhlSyfdCFBlcC5SAzzP+Y1frUkZDw==
X-Received: by 10.28.157.148 with SMTP id g142mr3096690wme.2.1470396044809; Fri, 05 Aug 2016 04:20:44 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id r127sm8137426wmf.23.2016.08.05.04.20.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Aug 2016 04:20:44 -0700 (PDT)
To: Nat Sakimura , John Bradley 
References:   <8F94CB33-41A6-438E-BE15-38A90FE653F5@oracle.com> <6a1e6f1e-16a3-c150-e057-a28a7d5b2b33@gmail.com> <5E317DFF-AE9B-4D18-9281-3C349AB57357@ve7jtb.com>  <7DE586FF-3450-4664-8CBC-85632B87A54D@ve7jtb.com> 
From: Sergey Beryozkin 
Message-ID: 
Date: Fri, 5 Aug 2016 12:20:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using IdToken instead of Access token
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, 05 Aug 2016 11:20:52 -0000

Hi Nat
On 05/08/16 11:16, Nat Sakimura wrote:
> I can sort of understand why people would want to do it, and there are
> legitimate cases.
>
> This is the case where the RS is in fact an AS (ASr)  in that resource
> domain and the RS is dependent on the federated AS (ASf) for the
> authentication. In such a case, the ASf cannot really make the access
> decision.
> It is the ASr that makes the decision based on the user authentication
> results, and possibly the authorisation result at ASf combined. To the
> ASf, the 'client' is the combination of the app that the user is using
> and the RS. So, the app sends the ID Token to the RS=ASr. This pattern
> is perfectly legitimate as long as the RS is also in the audience.
>
We've noticed that IdToken may have >1 audiences, in addition to the 
client audience, but were not sure what extra audiences would be there, 
so I can see now.

In this case, when RS acts as ASr, and IdToken lists this RS in the 
audience, is it still recommended for the client to exchange this 
IdToken for a new token via a token exchange endpoint and forwarding a 
new token to RS, or it it OK for the client to send the IdToken to RS 
bypassing the exchange ?

Thanks, Sergey

> Best,
>
> Nat
>
>
> 2016年8月5日(金) 5:58 John Bradley  >:
>
>     The token exchange spec allows for the token issued to have claims
>     about the subject of the input token.   This is what we generally
>     think about as impersonation.
>     That is really the same as a normal OAuth access token for the most
>     part.
>
>     You can also ask for a composite token that contains claims about
>     the presenter and the original subject.   This allows for the
>     auditing of who is making the request for the subject.
>
>     This sort of composite token was introduced in WS-Trust 1.4 and is
>     called ActAs in that spec and we refer to as delegation.
>
>     This is desired when a RS (A) receives a access token and then needs
>     to become a client (A) to access another service in the context of
>     the access token.
>
>     The second RS (B) is protected and can’t be access directly by the
>     the original OAuth client.  The client (A) needs a new access token
>     based on its client credential plus the original access token to get
>     a token that RS (B)  will accept.   RS (B) also wants to know who
>     the client that is accessing it for audit or other reasons.
>
>     That is one of the things that the new delegated token type is for.
>     The impersonation type is basically the same sort of impersonation
>     type token that we use now.
>
>     I admit that OAuth is vague about delegation vs impersonation and
>     they are generally left as implementation decisions as the tokens
>     are considered opaque.
>
>     For token exchange we wanted to be more explicit so that the client
>     has more control over the exchange.
>
>     I hope that helps.
>
>     John B.
>
>     > On Aug 4, 2016, at 12:26 PM, Sergey Beryozkin
>     > wrote:
>     >
>     > Hi John
>     >
>     > I think it is closer to what I'm trying to understand :-). Let me
>     work with the text below, I'll likely have few more questions to
>     follow later on
>     >
>     > Thanks, Sergey
>     >
>     > On 04/08/16 17:04, John Bradley wrote:
>     >> The id_token and access token have different semantics, and quite
>     possable possibly formats.
>     >>
>     >> So the AT that comes with the id_token will be useful at RS
>     associated with the AS, but it may not be useful at other API the
>     client wants to access and that is generally where we run into the
>     use case for token exchange.
>     >>
>     >> In the case of talking to a third party API it may be useful to
>     have that API have a token exchange endpoint where a client can
>     exchange a id_token/JWT for an access token.
>     >> That is clearer and likely more secure given a confidential
>     client  than just using the id_token as a access token directly.
>     >>
>     >> Now I do understand people do that now.
>     >>
>     >> In the hopefully near future once we have token binding as a
>     proof of possession mechanism it will be come clearer that you cant
>     take a id_token that is bound to the browser presenting the token to
>     the client and directly re use that as a secure access token.   The
>     AT and RT issued with that token will be bound to the client so that
>     the RS can validate them.
>     >>
>     >> There are a lot of bad patterns possible with bearer tokens.   I
>     prefer to try to avoid them so that people will be in a better
>     position when we move off bearer tokens for increased security.
>     >>
>     >> John B.
>     >>> On Aug 4, 2016, at 11:17 AM, Sergey Beryozkin
>     > wrote:
>     >>>
>     >>> Hi Phil
>     >>>
>     >>> On 04/08/16 15:01, Phil Hunt (IDM) wrote:
>     >>>> You might be munging two different flows with different
>     semantics together.
>     >>>>
>     >>>> First flow is use oidc to authen the user to the client.
>     >>>>
>     >>>> Second flow is normal oauth authorization to get an at to
>     access the resource.
>     >>>>
>     >>>> Often the OP AS is different from the RS's AS and the rs needs
>     a proper "delegation" access token.
>     >>> Indeed, this is more or less what I've been saying in our
>     private discussions.
>     >>>
>     >>> But as I said to in my response to Mike, I see a demand to have
>     IdToken propagated and given the token exchange draft has a
>     dedicated 'impersonation' section I'm assuming there's a need for it.
>     >>>
>     >>> For example, I was checking the archives, could see Brian
>     Campbell quoting Vittorio Bertocci:
>     >>> "To summarize our main use case: we use [a token exchange like
>     protocol] for achieving user impersonation thru tiers, or delegation
>     for confidential clients which do not have any web UX..."
>     >>>
>     >>> The former case there suggests that if a client has a web UI
>     they authenticate the user first and then start impersonating.
>     >>>
>     >>> I'm advocating for the clients to use the access tokens. The
>     clients can requests the extra scopes while authenticating the user
>     and if the user approves these scopes the client can continue using
>     AT on behalf of the client, and using IdToken to only interact with
>     the user.
>     >>>
>     >>> But I'm finding it difficult to explain (show a clear
>     differentiator) when the client should use AT and when they should
>     use IdToken to impersonate a user and get a new token (via the token
>     exchange)...
>     >>>
>     >>> Sergey
>     >>>>
>     >>>> Phil
>     >>>>
>     >>>>> On Aug 4, 2016, at 6:00 AM, Mike Schwartz      > wrote:
>     >>>>>
>     >>>>> Sergey,
>     >>>>>
>     >>>>> Since no one answered your question, let me pose a few
>     questions to your questions!
>     >>>>>
>     >>>>> Wouldn't it give you more flexibility to issue a different
>     token to
>     >>>>> represent access to the RS API? In terms of passing user claims,
>     >>>>> couldn't this be done via parameters in the API? Are you
>     trying to do
>     >>>>> more with OpenID Connect than was anticpiated in the design?
>     >>>>> The id_token has an audience, are you including more than one
>     client in that
>     >>>>> audience? Would it make sense to look at token exchange and
>     downscope the token?
>     >>>>> If you are looking for a profile of OAuth2, might UMA work?
>     >>>>>
>     >>>>> I think you're not alone in wondering what the answer to all
>     these questions are..
>     >>>>>
>     >>>>> - Mike
>     >>>>>
>     >>>>>
>     >>>>> -------------------------------------
>     >>>>> Michael Schwartz
>     >>>>> Gluu
>     >>>>> http://gluu.org
>     >>>>>
>     >>>>>> Message: 3
>     >>>>>> Date: Wed, 3 Aug 2016 11:08:29 +0100
>     >>>>>> From: Sergey Beryozkin      >
>     >>>>>> To: "oauth@ietf.org "      >
>     >>>>>> Subject: [OAUTH-WG] Using IdToken instead of Access token
>     >>>>>> Message-ID:      >
>     >>>>>> Content-Type: text/plain; charset=windows-1252; format=flowed
>     >>>>>> Hi All
>     >>>>>> I hope this question is better suited for this list. Will have no
>     >>>>>> problems redirecting it to the openid-connect list instead.
>     >>>>>> Consider a user working with the client web application (OIDC
>     RP) which
>     >>>>>> authenticates the user with the OIDC authorization code flow
>     at the end
>     >>>>>> of which the client gets AccessToken + IdToken. Next the user
>     requests
>     >>>>>> something from the client which needs to access the RS to
>     complete this
>     >>>>>> request.
>     >>>>>> And the idea is to have the client pass IdToken to RS and use
>     various
>     >>>>>> user claims inside this IdToken to enforce the access control
>     at the RS
>     >>>>>> level. My position it is likely wrong but I guess I may be
>     missing
>     >>>>>> something that will be either in favor or against it.
>     >>>>>> The reason I think it is wrong is that if the client is using
>     a code
>     >>>>>> flow then the right approach for staying within the OAuth2
>     'world' is to
>     >>>>>> use the access token to talk to RS and use IdToken only for
>     the purpose
>     >>>>>> of interacting with the user. The access token represents a
>     proper user
>     >>>>>> authorization and can have the extra scopes in addition to
>     "oidc" which
>     >>>>>> RS can depend upon in its access control restrictions.
>     >>>>>> Next I'm arguing that if the IdToken is used instead then it
>     is the case
>     >>>>>> of the client impersonating the user. And refer to the STS
>     for the REST
>     >>>>>> of Us draft (I have a separate series of question on that
>     draft). I'm
>     >>>>>> saying the impersonation can work but ignoring the access tokens
>     >>>>>> completely will make the overall solution much less flexible.
>     >>>>>> I'd like to ask for some advice/guidance:
>     >>>>>> - Is it a good idea at all for the client to use IdToken
>     instead of
>     >>>>>> AccessToken as explored above ? I suppose it can work, in the
>     code flow
>     >>>>>> the client gets the access token which, by default, only
>     allows to
>     >>>>>> access UserInfo. Perhaps the client impersonating IdToken for the
>     >>>>>> purpose of accessing RS is not too bad after all.
>     >>>>>> - Assuming the impersonation is OK, what is the right
>     criteria for the
>     >>>>>> client to choose to work with IdToken instead of the access
>     token when
>     >>>>>> accessing the immediate RS. It seems like if the
>     impersonation is OK for
>     >>>>>> the client to do then why have access tokens at all...
>     >>>>>> - Assuming the impersonation is OK, does STS For the REST of
>     Us shows
>     >>>>>> the right and the only way it needs to be done ? I can
>     imagine how it
>     >>>>>> will work for the web app clients, but what about Implicit
>     Clients.
>     >>>>>> Many thanks, Sergey
>     >>>>>
>     >>>>> _______________________________________________
>     >>>>> 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
>     >>>>
>     >>>
>     >>>
>     >>> --
>     >>> Sergey Beryozkin
>     >>>
>     >>> Talend Community Coders
>     >>> http://coders.talend.com/
>     >>>
>     >>> _______________________________________________
>     >>> OAuth mailing list
>     >>> OAuth@ietf.org 
>     >>> https://www.ietf.org/mailman/listinfo/oauth
>     >>
>     >
>     >
>     > --
>     > Sergey Beryozkin
>     >
>     > Talend Community Coders
>     > http://coders.talend.com/
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
> --
>
> Nat Sakimura
>
> Chairman of the Board, OpenID Foundation
>


From nobody Fri Aug  5 07:47:12 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B072812D899 for ; Fri,  5 Aug 2016 07:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ung4E6vsN93m for ; Fri,  5 Aug 2016 07:47:06 -0700 (PDT)
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 0869112D898 for ; Fri,  5 Aug 2016 07:47:06 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id x185so72098074qkc.2 for ; Fri, 05 Aug 2016 07:47:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MtZ1fNyk1vuGGCeX03y6wS+MCZ3i/Jr8gdasVCHArT0=; b=GCBSGkTvIcAcvDozHJf+Df6DhBmdF9Vz8i1AtEd2gnWOjHOeh7a7yByAzMlFKJBg/n jzpN6CkBRwe+TlGG3cY+OSujrmHk/TwVI93puKzlDIw+cBw2fNiZzLZIwH4dTTwQVVRs 0byDcE6IQGEySaYCuTX472YD+tgJHkLFdrGrINEBH9K+ls5WosWglAIfYldKtRzgPbtv 7rp4O/imJaQpHY0JaMW4A30a+dcwhIb5t/3WeOXGzSNnweiYCHVJdadhM9+DsOfvtVoC X+Ttv+5PH2WaQ2r/WalwpWGvrLjWuOLghsH1xFpQAhJBlKf1934Q2Lrw7SApz8z/vyb5 tPCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MtZ1fNyk1vuGGCeX03y6wS+MCZ3i/Jr8gdasVCHArT0=; b=iPPrR1fXIEqW5kTfsv4RE9Z4IJlvH+e4a5y1aNGmSpZXFs8F/bZd+6EM/547sGwnFS WTb6h84bvmb6yHtkcr9Ju06b9PEiuRyBjDw+JO5fdnV8d9sq2i+P6csg5lgPzgXP7w7K YcBrEZt0eqD8qiu9Mo+EJuRjX4kXp4NMvz0LcJHRZ2jFWMYQR4bWlTSkEkNoWmXYk3Ch 7QDDqsmYyzXM8uLDE6CtvpE95MuANHFkJH9aa5gBbb9B6Ou9cfvXgOREJDIU62pYWlfO sOm0g2vrQagJwnj4I99rykpyeTwlZ08187NvSyogdnm0GTIFGyqQJ7vbA9vn2Zxa2t4H 2IPg==
X-Gm-Message-State: AEkoouv/pMERfaMbH7iwWeBaadbmS1xV/L8gPBJDcdOGMDZMDDyOGmJHypLQEdVPkkpxyR/rEzKc7M+CzyTPUg==
X-Received: by 10.55.82.2 with SMTP id g2mr13043625qkb.101.1470408424997; Fri, 05 Aug 2016 07:47:04 -0700 (PDT)
MIME-Version: 1.0
References:   <8F94CB33-41A6-438E-BE15-38A90FE653F5@oracle.com> <6a1e6f1e-16a3-c150-e057-a28a7d5b2b33@gmail.com> <5E317DFF-AE9B-4D18-9281-3C349AB57357@ve7jtb.com>  <7DE586FF-3450-4664-8CBC-85632B87A54D@ve7jtb.com>  
In-Reply-To: 
From: Nat Sakimura 
Date: Fri, 05 Aug 2016 14:46:54 +0000
Message-ID: 
To: Sergey Beryozkin , John Bradley 
Content-Type: multipart/alternative; boundary=001a114a856ed8c7c505395423ff
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using IdToken instead of Access token
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, 05 Aug 2016 14:47:10 -0000

--001a114a856ed8c7c505395423ff
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The token exchange endpoint at ASf has no ability to issue a usable access
token in this case. The client has to talk to the token exchange endpoint
at ASr to get an access token to be used at the RS, IMHO.

2016=E5=B9=B48=E6=9C=885=E6=97=A5(=E9=87=91) 20:20 Sergey Beryozkin :

> Hi Nat
> On 05/08/16 11:16, Nat Sakimura wrote:
> > I can sort of understand why people would want to do it, and there are
> > legitimate cases.
> >
> > This is the case where the RS is in fact an AS (ASr)  in that resource
> > domain and the RS is dependent on the federated AS (ASf) for the
> > authentication. In such a case, the ASf cannot really make the access
> > decision.
> > It is the ASr that makes the decision based on the user authentication
> > results, and possibly the authorisation result at ASf combined. To the
> > ASf, the 'client' is the combination of the app that the user is using
> > and the RS. So, the app sends the ID Token to the RS=3DASr. This patter=
n
> > is perfectly legitimate as long as the RS is also in the audience.
> >
> We've noticed that IdToken may have >1 audiences, in addition to the
> client audience, but were not sure what extra audiences would be there,
> so I can see now.
>
> In this case, when RS acts as ASr, and IdToken lists this RS in the
> audience, is it still recommended for the client to exchange this
> IdToken for a new token via a token exchange endpoint and forwarding a
> new token to RS, or it it OK for the client to send the IdToken to RS
> bypassing the exchange ?
>
> Thanks, Sergey
>
> > Best,
> >
> > Nat
> >
> >
> > 2016=E5=B9=B48=E6=9C=885=E6=97=A5(=E9=87=91) 5:58 John Bradley  > >:
> >
> >     The token exchange spec allows for the token issued to have claims
> >     about the subject of the input token.   This is what we generally
> >     think about as impersonation.
> >     That is really the same as a normal OAuth access token for the most
> >     part.
> >
> >     You can also ask for a composite token that contains claims about
> >     the presenter and the original subject.   This allows for the
> >     auditing of who is making the request for the subject.
> >
> >     This sort of composite token was introduced in WS-Trust 1.4 and is
> >     called ActAs in that spec and we refer to as delegation.
> >
> >     This is desired when a RS (A) receives a access token and then need=
s
> >     to become a client (A) to access another service in the context of
> >     the access token.
> >
> >     The second RS (B) is protected and can=E2=80=99t be access directly=
 by the
> >     the original OAuth client.  The client (A) needs a new access token
> >     based on its client credential plus the original access token to ge=
t
> >     a token that RS (B)  will accept.   RS (B) also wants to know who
> >     the client that is accessing it for audit or other reasons.
> >
> >     That is one of the things that the new delegated token type is for.
> >     The impersonation type is basically the same sort of impersonation
> >     type token that we use now.
> >
> >     I admit that OAuth is vague about delegation vs impersonation and
> >     they are generally left as implementation decisions as the tokens
> >     are considered opaque.
> >
> >     For token exchange we wanted to be more explicit so that the client
> >     has more control over the exchange.
> >
> >     I hope that helps.
> >
> >     John B.
> >
> >     > On Aug 4, 2016, at 12:26 PM, Sergey Beryozkin
> >     > wrote:
> >     >
> >     > Hi John
> >     >
> >     > I think it is closer to what I'm trying to understand :-). Let me
> >     work with the text below, I'll likely have few more questions to
> >     follow later on
> >     >
> >     > Thanks, Sergey
> >     >
> >     > On 04/08/16 17:04, John Bradley wrote:
> >     >> The id_token and access token have different semantics, and quit=
e
> >     possable possibly formats.
> >     >>
> >     >> So the AT that comes with the id_token will be useful at RS
> >     associated with the AS, but it may not be useful at other API the
> >     client wants to access and that is generally where we run into the
> >     use case for token exchange.
> >     >>
> >     >> In the case of talking to a third party API it may be useful to
> >     have that API have a token exchange endpoint where a client can
> >     exchange a id_token/JWT for an access token.
> >     >> That is clearer and likely more secure given a confidential
> >     client  than just using the id_token as a access token directly.
> >     >>
> >     >> Now I do understand people do that now.
> >     >>
> >     >> In the hopefully near future once we have token binding as a
> >     proof of possession mechanism it will be come clearer that you cant
> >     take a id_token that is bound to the browser presenting the token t=
o
> >     the client and directly re use that as a secure access token.   The
> >     AT and RT issued with that token will be bound to the client so tha=
t
> >     the RS can validate them.
> >     >>
> >     >> There are a lot of bad patterns possible with bearer tokens.   I
> >     prefer to try to avoid them so that people will be in a better
> >     position when we move off bearer tokens for increased security.
> >     >>
> >     >> John B.
> >     >>> On Aug 4, 2016, at 11:17 AM, Sergey Beryozkin
> >     > wrote:
> >     >>>
> >     >>> Hi Phil
> >     >>>
> >     >>> On 04/08/16 15:01, Phil Hunt (IDM) wrote:
> >     >>>> You might be munging two different flows with different
> >     semantics together.
> >     >>>>
> >     >>>> First flow is use oidc to authen the user to the client.
> >     >>>>
> >     >>>> Second flow is normal oauth authorization to get an at to
> >     access the resource.
> >     >>>>
> >     >>>> Often the OP AS is different from the RS's AS and the rs needs
> >     a proper "delegation" access token.
> >     >>> Indeed, this is more or less what I've been saying in our
> >     private discussions.
> >     >>>
> >     >>> But as I said to in my response to Mike, I see a demand to have
> >     IdToken propagated and given the token exchange draft has a
> >     dedicated 'impersonation' section I'm assuming there's a need for i=
t.
> >     >>>
> >     >>> For example, I was checking the archives, could see Brian
> >     Campbell quoting Vittorio Bertocci:
> >     >>> "To summarize our main use case: we use [a token exchange like
> >     protocol] for achieving user impersonation thru tiers, or delegatio=
n
> >     for confidential clients which do not have any web UX..."
> >     >>>
> >     >>> The former case there suggests that if a client has a web UI
> >     they authenticate the user first and then start impersonating.
> >     >>>
> >     >>> I'm advocating for the clients to use the access tokens. The
> >     clients can requests the extra scopes while authenticating the user
> >     and if the user approves these scopes the client can continue using
> >     AT on behalf of the client, and using IdToken to only interact with
> >     the user.
> >     >>>
> >     >>> But I'm finding it difficult to explain (show a clear
> >     differentiator) when the client should use AT and when they should
> >     use IdToken to impersonate a user and get a new token (via the toke=
n
> >     exchange)...
> >     >>>
> >     >>> Sergey
> >     >>>>
> >     >>>> Phil
> >     >>>>
> >     >>>>> On Aug 4, 2016, at 6:00 AM, Mike Schwartz  >     > wrote:
> >     >>>>>
> >     >>>>> Sergey,
> >     >>>>>
> >     >>>>> Since no one answered your question, let me pose a few
> >     questions to your questions!
> >     >>>>>
> >     >>>>> Wouldn't it give you more flexibility to issue a different
> >     token to
> >     >>>>> represent access to the RS API? In terms of passing user
> claims,
> >     >>>>> couldn't this be done via parameters in the API? Are you
> >     trying to do
> >     >>>>> more with OpenID Connect than was anticpiated in the design?
> >     >>>>> The id_token has an audience, are you including more than one
> >     client in that
> >     >>>>> audience? Would it make sense to look at token exchange and
> >     downscope the token?
> >     >>>>> If you are looking for a profile of OAuth2, might UMA work?
> >     >>>>>
> >     >>>>> I think you're not alone in wondering what the answer to all
> >     these questions are..
> >     >>>>>
> >     >>>>> - Mike
> >     >>>>>
> >     >>>>>
> >     >>>>> -------------------------------------
> >     >>>>> Michael Schwartz
> >     >>>>> Gluu
> >     >>>>> http://gluu.org
> >     >>>>>
> >     >>>>>> Message: 3
> >     >>>>>> Date: Wed, 3 Aug 2016 11:08:29 +0100
> >     >>>>>> From: Sergey Beryozkin  >     >
> >     >>>>>> To: "oauth@ietf.org "  >     >
> >     >>>>>> Subject: [OAUTH-WG] Using IdToken instead of Access token
> >     >>>>>> Message-ID:  >     >
> >     >>>>>> Content-Type: text/plain; charset=3Dwindows-1252; format=3Df=
lowed
> >     >>>>>> Hi All
> >     >>>>>> I hope this question is better suited for this list. Will
> have no
> >     >>>>>> problems redirecting it to the openid-connect list instead.
> >     >>>>>> Consider a user working with the client web application (OID=
C
> >     RP) which
> >     >>>>>> authenticates the user with the OIDC authorization code flow
> >     at the end
> >     >>>>>> of which the client gets AccessToken + IdToken. Next the use=
r
> >     requests
> >     >>>>>> something from the client which needs to access the RS to
> >     complete this
> >     >>>>>> request.
> >     >>>>>> And the idea is to have the client pass IdToken to RS and us=
e
> >     various
> >     >>>>>> user claims inside this IdToken to enforce the access contro=
l
> >     at the RS
> >     >>>>>> level. My position it is likely wrong but I guess I may be
> >     missing
> >     >>>>>> something that will be either in favor or against it.
> >     >>>>>> The reason I think it is wrong is that if the client is usin=
g
> >     a code
> >     >>>>>> flow then the right approach for staying within the OAuth2
> >     'world' is to
> >     >>>>>> use the access token to talk to RS and use IdToken only for
> >     the purpose
> >     >>>>>> of interacting with the user. The access token represents a
> >     proper user
> >     >>>>>> authorization and can have the extra scopes in addition to
> >     "oidc" which
> >     >>>>>> RS can depend upon in its access control restrictions.
> >     >>>>>> Next I'm arguing that if the IdToken is used instead then it
> >     is the case
> >     >>>>>> of the client impersonating the user. And refer to the STS
> >     for the REST
> >     >>>>>> of Us draft (I have a separate series of question on that
> >     draft). I'm
> >     >>>>>> saying the impersonation can work but ignoring the access
> tokens
> >     >>>>>> completely will make the overall solution much less flexible=
.
> >     >>>>>> I'd like to ask for some advice/guidance:
> >     >>>>>> - Is it a good idea at all for the client to use IdToken
> >     instead of
> >     >>>>>> AccessToken as explored above ? I suppose it can work, in th=
e
> >     code flow
> >     >>>>>> the client gets the access token which, by default, only
> >     allows to
> >     >>>>>> access UserInfo. Perhaps the client impersonating IdToken fo=
r
> the
> >     >>>>>> purpose of accessing RS is not too bad after all.
> >     >>>>>> - Assuming the impersonation is OK, what is the right
> >     criteria for the
> >     >>>>>> client to choose to work with IdToken instead of the access
> >     token when
> >     >>>>>> accessing the immediate RS. It seems like if the
> >     impersonation is OK for
> >     >>>>>> the client to do then why have access tokens at all...
> >     >>>>>> - Assuming the impersonation is OK, does STS For the REST of
> >     Us shows
> >     >>>>>> the right and the only way it needs to be done ? I can
> >     imagine how it
> >     >>>>>> will work for the web app clients, but what about Implicit
> >     Clients.
> >     >>>>>> Many thanks, Sergey
> >     >>>>>
> >     >>>>> _______________________________________________
> >     >>>>> 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
> >     >>>>
> >     >>>
> >     >>>
> >     >>> --
> >     >>> Sergey Beryozkin
> >     >>>
> >     >>> Talend Community Coders
> >     >>> http://coders.talend.com/
> >     >>>
> >     >>> _______________________________________________
> >     >>> OAuth mailing list
> >     >>> OAuth@ietf.org 
> >     >>> https://www.ietf.org/mailman/listinfo/oauth
> >     >>
> >     >
> >     >
> >     > --
> >     > Sergey Beryozkin
> >     >
> >     > Talend Community Coders
> >     > http://coders.talend.com/
> >
> >     _______________________________________________
> >     OAuth mailing list
> >     OAuth@ietf.org 
> >     https://www.ietf.org/mailman/listinfo/oauth
> >
> > --
> >
> > Nat Sakimura
> >
> > Chairman of the Board, OpenID Foundation
> >
>
> --

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a114a856ed8c7c505395423ff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


The token exchange endpoint at ASf has no ability to issue a=
 usable access token in this case. The client has to talk to the token exch=
ange endpoint at ASr to get an access token to be used at the RS, IMHO. 

2016=E5=B9=B48=E6=9C=885=E6=
=97=A5(=E9=87=91) 20:20 Sergey Beryozkin <sberyozkin@gmail.com>:
Hi Nat

On 05/08/16 11:16, Nat Sakimura wrote:

> I can sort of understand why people would want to do it, and there are=


> legitimate cases.

>

> This is the case where the RS is in fact an AS (ASr)=C2=A0 in that res=
ource

> domain and the RS is dependent on the federated AS (ASf) for the

> authentication. In such a case, the ASf cannot really make the access<=
br>
> decision.

> It is the ASr that makes the decision based on the user authentication=


> results, and possibly the authorisation result at ASf combined. To the=


> ASf, the 'client' is the combination of the app that the user =
is using

> and the RS. So, the app sends the ID Token to the RS=3DASr. This patte=
rn

> is perfectly legitimate as long as the RS is also in the audience.

>

We've noticed that IdToken may have >1 audiences, in addition to the=


client audience, but were not sure what extra audiences would be there,

so I can see now.



In this case, when RS acts as ASr, and IdToken lists this RS in the

audience, is it still recommended for the client to exchange this

IdToken for a new token via a token exchange endpoint and forwarding a

new token to RS, or it it OK for the client to send the IdToken to RS

bypassing the exchange ?



Thanks, Sergey



> Best,

>

> Nat

>

>

> 2016=E5=B9=B48=E6=9C=885=E6=97=A5(=E9=87=91) 5:58 John Bradley <ve7jtb@ve7jtb.com
> <mailto:ve7j=
tb@ve7jtb.com>>:

>

>=C2=A0 =C2=A0 =C2=A0The token exchange spec allows for the token issued=
 to have claims

>=C2=A0 =C2=A0 =C2=A0about the subject of the input token.=C2=A0 =C2=A0T=
his is what we generally

>=C2=A0 =C2=A0 =C2=A0think about as impersonation.

>=C2=A0 =C2=A0 =C2=A0That is really the same as a normal OAuth access to=
ken for the most

>=C2=A0 =C2=A0 =C2=A0part.

>

>=C2=A0 =C2=A0 =C2=A0You can also ask for a composite token that contain=
s claims about

>=C2=A0 =C2=A0 =C2=A0the presenter and the original subject.=C2=A0 =C2=
=A0This allows for the

>=C2=A0 =C2=A0 =C2=A0auditing of who is making the request for the subje=
ct.

>

>=C2=A0 =C2=A0 =C2=A0This sort of composite token was introduced in WS-T=
rust 1.4 and is

>=C2=A0 =C2=A0 =C2=A0called ActAs in that spec and we refer to as delega=
tion.

>

>=C2=A0 =C2=A0 =C2=A0This is desired when a RS (A) receives a access tok=
en and then needs

>=C2=A0 =C2=A0 =C2=A0to become a client (A) to access another service in=
 the context of

>=C2=A0 =C2=A0 =C2=A0the access token.

>

>=C2=A0 =C2=A0 =C2=A0The second RS (B) is protected and can=E2=80=99t be=
 access directly by the

>=C2=A0 =C2=A0 =C2=A0the original OAuth client.=C2=A0 The client (A) nee=
ds a new access token

>=C2=A0 =C2=A0 =C2=A0based on its client credential plus the original ac=
cess token to get

>=C2=A0 =C2=A0 =C2=A0a token that RS (B)=C2=A0 will accept.=C2=A0 =C2=A0=
RS (B) also wants to know who

>=C2=A0 =C2=A0 =C2=A0the client that is accessing it for audit or other =
reasons.

>

>=C2=A0 =C2=A0 =C2=A0That is one of the things that the new delegated to=
ken type is for.

>=C2=A0 =C2=A0 =C2=A0The impersonation type is basically the same sort o=
f impersonation

>=C2=A0 =C2=A0 =C2=A0type token that we use now.

>

>=C2=A0 =C2=A0 =C2=A0I admit that OAuth is vague about delegation vs imp=
ersonation and

>=C2=A0 =C2=A0 =C2=A0they are generally left as implementation decisions=
 as the tokens

>=C2=A0 =C2=A0 =C2=A0are considered opaque.

>

>=C2=A0 =C2=A0 =C2=A0For token exchange we wanted to be more explicit so=
 that the client

>=C2=A0 =C2=A0 =C2=A0has more control over the exchange.

>

>=C2=A0 =C2=A0 =C2=A0I hope that helps.

>

>=C2=A0 =C2=A0 =C2=A0John B.

>

>=C2=A0 =C2=A0 =C2=A0> On Aug 4, 2016, at 12:26 PM, Sergey Beryozkin<=
br>
>=C2=A0 =C2=A0 =C2=A0<sberyozkin@gmail.com <mailto:sberyozkin@gmail.com>> wrote:

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> Hi John

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> I think it is closer to what I'm trying to=
 understand :-). Let me

>=C2=A0 =C2=A0 =C2=A0work with the text below, I'll likely have few =
more questions to

>=C2=A0 =C2=A0 =C2=A0follow later on

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> Thanks, Sergey

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> On 04/08/16 17:04, John Bradley wrote:

>=C2=A0 =C2=A0 =C2=A0>> The id_token and access token have differe=
nt semantics, and quite

>=C2=A0 =C2=A0 =C2=A0possable possibly formats.

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> So the AT that comes with the id_token wil=
l be useful at RS

>=C2=A0 =C2=A0 =C2=A0associated with the AS, but it may not be useful at=
 other API the

>=C2=A0 =C2=A0 =C2=A0client wants to access and that is generally where =
we run into the

>=C2=A0 =C2=A0 =C2=A0use case for token exchange.

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> In the case of talking to a third party AP=
I it may be useful to

>=C2=A0 =C2=A0 =C2=A0have that API have a token exchange endpoint where =
a client can

>=C2=A0 =C2=A0 =C2=A0exchange a id_token/JWT for an access token.

>=C2=A0 =C2=A0 =C2=A0>> That is clearer and likely more secure giv=
en a confidential

>=C2=A0 =C2=A0 =C2=A0client=C2=A0 than just using the id_token as a acce=
ss token directly.

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> Now I do understand people do that now.
>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> In the hopefully near future once we have =
token binding as a

>=C2=A0 =C2=A0 =C2=A0proof of possession mechanism it will be come clear=
er that you cant

>=C2=A0 =C2=A0 =C2=A0take a id_token that is bound to the browser presen=
ting the token to

>=C2=A0 =C2=A0 =C2=A0the client and directly re use that as a secure acc=
ess token.=C2=A0 =C2=A0The

>=C2=A0 =C2=A0 =C2=A0AT and RT issued with that token will be bound to t=
he client so that

>=C2=A0 =C2=A0 =C2=A0the RS can validate them.

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> There are a lot of bad patterns possible w=
ith bearer tokens.=C2=A0 =C2=A0I

>=C2=A0 =C2=A0 =C2=A0prefer to try to avoid them so that people will be =
in a better

>=C2=A0 =C2=A0 =C2=A0position when we move off bearer tokens for increas=
ed security.

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>> John B.

>=C2=A0 =C2=A0 =C2=A0>>> On Aug 4, 2016, at 11:17 AM, Sergey Be=
ryozkin

>=C2=A0 =C2=A0 =C2=A0<sberyozkin@gmail.com <mailto:sberyozkin@gmail.com>> wrote:

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> Hi Phil

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> On 04/08/16 15:01, Phil Hunt (IDM) wro=
te:

>=C2=A0 =C2=A0 =C2=A0>>>> You might be munging two different=
 flows with different

>=C2=A0 =C2=A0 =C2=A0semantics together.

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> First flow is use oidc to authen t=
he user to the client.

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> Second flow is normal oauth author=
ization to get an at to

>=C2=A0 =C2=A0 =C2=A0access the resource.

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> Often the OP AS is different from =
the RS's AS and the rs needs

>=C2=A0 =C2=A0 =C2=A0a proper "delegation" access token.

>=C2=A0 =C2=A0 =C2=A0>>> Indeed, this is more or less what I=
9;ve been saying in our

>=C2=A0 =C2=A0 =C2=A0private discussions.

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> But as I said to in my response to Mik=
e, I see a demand to have

>=C2=A0 =C2=A0 =C2=A0IdToken propagated and given the token exchange dra=
ft has a

>=C2=A0 =C2=A0 =C2=A0dedicated 'impersonation' section I'm a=
ssuming there's a need for it.

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> For example, I was checking the archiv=
es, could see Brian

>=C2=A0 =C2=A0 =C2=A0Campbell quoting Vittorio Bertocci:

>=C2=A0 =C2=A0 =C2=A0>>> "To summarize our main use case: =
we use [a token exchange like

>=C2=A0 =C2=A0 =C2=A0protocol] for achieving user impersonation thru tie=
rs, or delegation

>=C2=A0 =C2=A0 =C2=A0for confidential clients which do not have any web =
UX..."

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> The former case there suggests that if=
 a client has a web UI

>=C2=A0 =C2=A0 =C2=A0they authenticate the user first and then start imp=
ersonating.

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> I'm advocating for the clients to =
use the access tokens. The

>=C2=A0 =C2=A0 =C2=A0clients can requests the extra scopes while authent=
icating the user

>=C2=A0 =C2=A0 =C2=A0and if the user approves these scopes the client ca=
n continue using

>=C2=A0 =C2=A0 =C2=A0AT on behalf of the client, and using IdToken to on=
ly interact with

>=C2=A0 =C2=A0 =C2=A0the user.

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> But I'm finding it difficult to ex=
plain (show a clear

>=C2=A0 =C2=A0 =C2=A0differentiator) when the client should use AT and w=
hen they should

>=C2=A0 =C2=A0 =C2=A0use IdToken to impersonate a user and get a new tok=
en (via the token

>=C2=A0 =C2=A0 =C2=A0exchange)...

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> Sergey

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> Phil

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> On Aug 4, 2016, at 6:00 AM, Mi=
ke Schwartz <mike@glu=
u.org

>=C2=A0 =C2=A0 =C2=A0<mailto:mike@gluu.org>> wrote:

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> Sergey,

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> Since no one answered your que=
stion, let me pose a few

>=C2=A0 =C2=A0 =C2=A0questions to your questions!

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> Wouldn't it give you more =
flexibility to issue a different

>=C2=A0 =C2=A0 =C2=A0token to

>=C2=A0 =C2=A0 =C2=A0>>>>> represent access to the RS API=
? In terms of passing user claims,

>=C2=A0 =C2=A0 =C2=A0>>>>> couldn't this be done via =
parameters in the API? Are you

>=C2=A0 =C2=A0 =C2=A0trying to do

>=C2=A0 =C2=A0 =C2=A0>>>>> more with OpenID Connect than =
was anticpiated in the design?

>=C2=A0 =C2=A0 =C2=A0>>>>> The id_token has an audience, =
are you including more than one

>=C2=A0 =C2=A0 =C2=A0client in that

>=C2=A0 =C2=A0 =C2=A0>>>>> audience? Would it make sense =
to look at token exchange and

>=C2=A0 =C2=A0 =C2=A0downscope the token?

>=C2=A0 =C2=A0 =C2=A0>>>>> If you are looking for a profi=
le of OAuth2, might UMA work?

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> I think you're not alone i=
n wondering what the answer to all

>=C2=A0 =C2=A0 =C2=A0these questions are..

>=C2=A0 =C2=A0 =C2=A0>>>>>

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

>=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 Schwartz

>=C2=A0 =C2=A0 =C2=A0>>>>> Gluu

>=C2=A0 =C2=A0 =C2=A0>>>>> http://gluu.org

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> Message: 3

>=C2=A0 =C2=A0 =C2=A0>>>>>> Date: Wed, 3 Aug 2016 11:0=
8:29 +0100

>=C2=A0 =C2=A0 =C2=A0>>>>>> From: Sergey Beryozkin <=
;sberyozkin@gmail=
.com

>=C2=A0 =C2=A0 =C2=A0<mailto:sberyozkin@gmail.com>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> To: "oauth@ietf.org <mailto:oauth@ietf.org>" &=
lt;oauth@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:oauth@ietf.org>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> Subject: [OAUTH-WG] Using =
IdToken instead of Access token

>=C2=A0 =C2=A0 =C2=A0>>>>>> Message-ID: <b=
026f4fc-3e08-4e00-02c3-84be2dc4b2bb@gmail.com

>=C2=A0 =C2=A0 =C2=A0<mailto:b026f4fc-3e08-4e00-02c3-84be2dc=
4b2bb@gmail.com>>

>=C2=A0 =C2=A0 =C2=A0>>>>>> Content-Type: text/plain; =
charset=3Dwindows-1252; format=3Dflowed

>=C2=A0 =C2=A0 =C2=A0>>>>>> Hi All

>=C2=A0 =C2=A0 =C2=A0>>>>>> I hope this question is be=
tter suited for this list. Will have no

>=C2=A0 =C2=A0 =C2=A0>>>>>> problems redirecting it to=
 the openid-connect list instead.

>=C2=A0 =C2=A0 =C2=A0>>>>>> Consider a user working wi=
th the client web application (OIDC

>=C2=A0 =C2=A0 =C2=A0RP) which

>=C2=A0 =C2=A0 =C2=A0>>>>>> authenticates the user wit=
h the OIDC authorization code flow

>=C2=A0 =C2=A0 =C2=A0at the end

>=C2=A0 =C2=A0 =C2=A0>>>>>> of which the client gets A=
ccessToken + IdToken. Next the user

>=C2=A0 =C2=A0 =C2=A0requests

>=C2=A0 =C2=A0 =C2=A0>>>>>> something from the client =
which needs to access the RS to

>=C2=A0 =C2=A0 =C2=A0complete this

>=C2=A0 =C2=A0 =C2=A0>>>>>> request.

>=C2=A0 =C2=A0 =C2=A0>>>>>> And the idea is to have th=
e client pass IdToken to RS and use

>=C2=A0 =C2=A0 =C2=A0various

>=C2=A0 =C2=A0 =C2=A0>>>>>> user claims inside this Id=
Token to enforce the access control

>=C2=A0 =C2=A0 =C2=A0at the RS

>=C2=A0 =C2=A0 =C2=A0>>>>>> level. My position it is l=
ikely wrong but I guess I may be

>=C2=A0 =C2=A0 =C2=A0missing

>=C2=A0 =C2=A0 =C2=A0>>>>>> something that will be eit=
her in favor or against it.

>=C2=A0 =C2=A0 =C2=A0>>>>>> The reason I think it is w=
rong is that if the client is using

>=C2=A0 =C2=A0 =C2=A0a code

>=C2=A0 =C2=A0 =C2=A0>>>>>> flow then the right approa=
ch for staying within the OAuth2

>=C2=A0 =C2=A0 =C2=A0'world' is to

>=C2=A0 =C2=A0 =C2=A0>>>>>> use the access token to ta=
lk to RS and use IdToken only for

>=C2=A0 =C2=A0 =C2=A0the purpose

>=C2=A0 =C2=A0 =C2=A0>>>>>> of interacting with the us=
er. The access token represents a

>=C2=A0 =C2=A0 =C2=A0proper user

>=C2=A0 =C2=A0 =C2=A0>>>>>> authorization and can have=
 the extra scopes in addition to

>=C2=A0 =C2=A0 =C2=A0"oidc" which

>=C2=A0 =C2=A0 =C2=A0>>>>>> RS can depend upon in its =
access control restrictions.

>=C2=A0 =C2=A0 =C2=A0>>>>>> Next I'm arguing that =
if the IdToken is used instead then it

>=C2=A0 =C2=A0 =C2=A0is the case

>=C2=A0 =C2=A0 =C2=A0>>>>>> of the client impersonatin=
g the user. And refer to the STS

>=C2=A0 =C2=A0 =C2=A0for the REST

>=C2=A0 =C2=A0 =C2=A0>>>>>> of Us draft (I have a sepa=
rate series of question on that

>=C2=A0 =C2=A0 =C2=A0draft). I'm

>=C2=A0 =C2=A0 =C2=A0>>>>>> saying the impersonation c=
an work but ignoring the access tokens

>=C2=A0 =C2=A0 =C2=A0>>>>>> completely will make the o=
verall solution much less flexible.

>=C2=A0 =C2=A0 =C2=A0>>>>>> I'd like to ask for so=
me advice/guidance:

>=C2=A0 =C2=A0 =C2=A0>>>>>> - Is it a good idea at all=
 for the client to use IdToken

>=C2=A0 =C2=A0 =C2=A0instead of

>=C2=A0 =C2=A0 =C2=A0>>>>>> AccessToken as explored ab=
ove ? I suppose it can work, in the

>=C2=A0 =C2=A0 =C2=A0code flow

>=C2=A0 =C2=A0 =C2=A0>>>>>> the client gets the access=
 token which, by default, only

>=C2=A0 =C2=A0 =C2=A0allows to

>=C2=A0 =C2=A0 =C2=A0>>>>>> access UserInfo. Perhaps t=
he client impersonating IdToken for the

>=C2=A0 =C2=A0 =C2=A0>>>>>> purpose of accessing RS is=
 not too bad after all.

>=C2=A0 =C2=A0 =C2=A0>>>>>> - Assuming the impersonati=
on is OK, what is the right

>=C2=A0 =C2=A0 =C2=A0criteria for the

>=C2=A0 =C2=A0 =C2=A0>>>>>> client to choose to work w=
ith IdToken instead of the access

>=C2=A0 =C2=A0 =C2=A0token when

>=C2=A0 =C2=A0 =C2=A0>>>>>> accessing the immediate RS=
. It seems like if the

>=C2=A0 =C2=A0 =C2=A0impersonation is OK for

>=C2=A0 =C2=A0 =C2=A0>>>>>> the client to do then why =
have access tokens at all...

>=C2=A0 =C2=A0 =C2=A0>>>>>> - Assuming the impersonati=
on is OK, does STS For the REST of

>=C2=A0 =C2=A0 =C2=A0Us shows

>=C2=A0 =C2=A0 =C2=A0>>>>>> the right and the only way=
 it needs to be done ? I can

>=C2=A0 =C2=A0 =C2=A0imagine how it

>=C2=A0 =C2=A0 =C2=A0>>>>>> will work for the web app =
clients, but what about Implicit

>=C2=A0 =C2=A0 =C2=A0Clients.

>=C2=A0 =C2=A0 =C2=A0>>>>>> Many thanks, Sergey

>=C2=A0 =C2=A0 =C2=A0>>>>>

>=C2=A0 =C2=A0 =C2=A0>>>>> ______________________________=
_________________

>=C2=A0 =C2=A0 =C2=A0>>>>> OAuth mailing list

>=C2=A0 =C2=A0 =C2=A0>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>

>=C2=A0 =C2=A0 =C2=A0>>>>> https://www.=
ietf.org/mailman/listinfo/oauth

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>> __________________________________=
_____________

>=C2=A0 =C2=A0 =C2=A0>>>> OAuth mailing list

>=C2=A0 =C2=A0 =C2=A0>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>

>=C2=A0 =C2=A0 =C2=A0>>>> https://www.ietf=
.org/mailman/listinfo/oauth

>=C2=A0 =C2=A0 =C2=A0>>>>

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> --

>=C2=A0 =C2=A0 =C2=A0>>> Sergey Beryozkin

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> Talend Community Coders

>=C2=A0 =C2=A0 =C2=A0>>> http://coders.talend.com/

>=C2=A0 =C2=A0 =C2=A0>>>

>=C2=A0 =C2=A0 =C2=A0>>> ______________________________________=
_________

>=C2=A0 =C2=A0 =C2=A0>>> OAuth mailing list

>=C2=A0 =C2=A0 =C2=A0>>> OAuth@ietf.org <mailto:OAuth@ietf.org>

>=C2=A0 =C2=A0 =C2=A0>>> https://www.ietf.org=
/mailman/listinfo/oauth

>=C2=A0 =C2=A0 =C2=A0>>

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> --

>=C2=A0 =C2=A0 =C2=A0> Sergey Beryozkin

>=C2=A0 =C2=A0 =C2=A0>

>=C2=A0 =C2=A0 =C2=A0> Talend Community Coders

>=C2=A0 =C2=A0 =C2=A0> http://coders.talend.com/

>

>=C2=A0 =C2=A0 =C2=A0_______________________________________________

>=C2=A0 =C2=A0 =C2=A0OAuth mailing list

>=C2=A0 =C2=A0 =C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>

>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/list=
info/oauth

>

> --

>

> Nat Sakimura

>

> Chairman of the Board, OpenID Foundation

>




-- 
Nat Sakimura


Chairman of the Board, OpenID Foundation




--001a114a856ed8c7c505395423ff--


From nobody Fri Aug  5 11:22:06 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C511912D624 for ; Fri,  5 Aug 2016 11:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mfl2bsvvrEd for ; Fri,  5 Aug 2016 11:22:04 -0700 (PDT)
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 9C03812D09B for ; Fri,  5 Aug 2016 11:22:03 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id p129so9288023wmp.0 for ; Fri, 05 Aug 2016 11:22:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=0M2IrTJYbR69cT1VvBSJRlv7GTdGBjS0hEW7B6J4gAY=; b=KZ0c1rJUs/zVugNCfvyozWMR+73zAd7OCxYbqXY2GOl4yJO3k5Rn9e2B+JwwbeaJ3Y /H1ItLf8uB7T3Kq9x1jAehGfl4RNyy+IslQ8C98we7O7q6O7cT8eJahpkE0Q6DWJL4mr JqSjRw7R5thbLXg6CtTbe2AhcaYRpqxb3bCll6CPe5koO5XuzfB5qWuI7oexKXk+pg22 ebu1re/mScWq69yfHvQhILxwG6vhpn7jSZJrc2FnMC6NdodfkCNa4NbQ1ACCEcR6YSzL 28JDo7HuyZ5ktpD6GsZIAOtvysz97/+kbsp414SWUE93XsYrJ8SkuXU8p0NBZHh73zoo 6Iwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=0M2IrTJYbR69cT1VvBSJRlv7GTdGBjS0hEW7B6J4gAY=; b=Pj6DkUtc4QBwD1+lUHbdQAu6Ozv9yGdkdabJ/FpDhZ+ijU+PzOKIBpvKPPyqxk7W/U XVbRzXvV0LnJNBRGNr0jk/SB37j3UZEW95plN/558ey7gYYX0mRdKaHCw/zbotEQGTfH FO28sEfYtmNo77oZItUv6RXrFx5dq/lbdoykokPkQ5Ryy6niZQsq7cJupQcpGmEwx1Bu NMTqE5AFomluz+cZzixSWu55MclE7rW/fGZ1vkv2vrxyfeGY9LTxKYZcLkHQadTd7Gwa BVORz5NqWSr9IMbwo/9Z6jIum0Mj+/+Y3CWDgBjU2gf3VdDDcdPC4et8aOEb0PZbqtoB +pWg==
X-Gm-Message-State: AEkooutzThnuNVwm6ET0Ys6GvpPkiIvhkSA1JuLl+ekpUCj4tL8BavioRx34FzGOX0u4I8ZGxfNX/T1LYEt25A==
X-Received: by 10.194.35.42 with SMTP id e10mr72728952wjj.107.1470421321783; Fri, 05 Aug 2016 11:22:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.36.213 with HTTP; Fri, 5 Aug 2016 11:22:01 -0700 (PDT)
In-Reply-To: <20160803204950.9683.46415.idtracker@ietfa.amsl.com>
References: <20160803204950.9683.46415.idtracker@ietfa.amsl.com>
From: Pedro Felix 
Date: Fri, 5 Aug 2016 19:22:01 +0100
Message-ID: 
To: oauth list 
Content-Type: multipart/alternative; boundary=047d7b86c4508e211e0539572483
Archived-At: 
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-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: Fri, 05 Aug 2016 18:22:06 -0000

--047d7b86c4508e211e0539572483
Content-Type: text/plain; charset=UTF-8

Hi,

What's the proper way to provide feedback on the "OAuth 2.0 Authorization
Server Metadata" spec?
In my opinion, section 3.2 is unnecessarily constraining the use of HTTP to
transfer the metadata representation by mandating ("MUST") a 200 status
code on a successful response. For instance, the server may support caching
and conditional requests, where a 304 (Not Modified) also represents
success. Another example is if the server wants to direct the client to a
different URL by using a 301, 302, 307 or 308. A return with any of these
codes does not represent failure. It just means that an additional request
is required.

IMO, the spec should focus on the format semantics and leave the transfer
semantics for HTTP.

Regards
Pedro




On Wed, Aug 3, 2016 at 9:49 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol of the IETF.
>
>         Title           : OAuth 2.0 Authorization Server Metadata
>         Authors         : Michael B. Jones
>                           Nat Sakimura
>                           John Bradley
>         Filename        : draft-ietf-oauth-discovery-04.txt
>         Pages           : 23
>         Date            : 2016-08-03
>
> Abstract:
>    This specification defines a metadata format that an OAuth 2.0 client
>    can use to obtain the information needed to interact with an OAuth
>    2.0 authorization server, including its endpoint locations and
>    authorization server capabilities.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-discovery-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
>

--047d7b86c4508e211e0539572483
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

What's the proper way to provid=
e feedback on the "O=
Auth=C2=A02.0 Authorization Server Me=
tadata" spec?
In my opinion, section 3.2 is=C2=A0unne=
cessarily constraining the use of HTTP to transfer the metadata representat=
ion by mandating ("MUST") a 200 status code on a successful respo=
nse. For instance, the server may support caching and conditional requests,=
 where a 304 (Not Modified) also represents success. Another example is if =
the server wants to direct the client to a different URL by using a 301, 30=
2, 307 or 308. A return with any of these codes does not represent failure.=
 It just means that an additional request is required.

=

IMO, the spec should focus on the format semantics and leave the trans=
fer semantics for HTTP.

Regards
Pedro




=
On Wed, Aug 3, 2016 at 9:49 PM,  <internet-drafts@ietf.org><=
/span> 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 Authorization Server Metadata

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich=
ael 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 Nat Sakimura

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 John Bradley

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-oauth-discovery-04.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 23

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2016-08-03



Abstract:

=C2=A0 =C2=A0This specification defines a metadata format that an OAuth 2.0=
 client

=C2=A0 =C2=A0can use to obtain the information needed to interact with an O=
Auth

=C2=A0 =C2=A02.0 authorization server, including its endpoint locations and=


=C2=A0 =C2=A0authorization server capabilities.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/dr=
aft-ietf-oauth-discovery/



There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ie=
tf-oauth-discovery-04



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?u=
rl2=3Ddraft-ietf-oauth-discovery-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





--047d7b86c4508e211e0539572483--


From nobody Mon Aug  8 09:34:10 2016
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4480112D1B7; Mon,  8 Aug 2016 09:34:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147067404527.23058.17317554291756036969.idtracker@ietfa.amsl.com>
Date: Mon, 08 Aug 2016 09:34:05 -0700
Archived-At: 
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-signed-http-request-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: Mon, 08 Aug 2016 16:34:05 -0000

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

        Title           : A Method for Signing HTTP Requests for OAuth
        Authors         : Justin Richer
                          John Bradley
                          Hannes Tschofenig
	Filename        : draft-ietf-oauth-signed-http-request-03.txt
	Pages           : 13
	Date            : 2016-08-08

Abstract:
   This document a method for offering data origin authentication and
   integrity protection of HTTP requests.  To convey the relevant data
   items in the request a JSON-based encapsulation is used and the JSON
   Web Signature (JWS) technique is re-used.  JWS offers integrity
   protection using symmetric as well as asymmetric cryptography.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-signed-http-request-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 Mon Aug  8 12:32:24 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C2412B02B for ; Mon,  8 Aug 2016 12:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.468
X-Spam-Level: 
X-Spam-Status: No, score=-5.468 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, 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 uV7cVHHZK4nr for ; Mon,  8 Aug 2016 12:32:05 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7572612B004 for ; Mon,  8 Aug 2016 12:32:01 -0700 (PDT)
X-AuditID: 12074424-0c7ff70000002166-62-57a8de300c86
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 E9.32.08550.03ED8A75; Mon,  8 Aug 2016 15:32:00 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u78JVxdf029845; Mon, 8 Aug 2016 15:31:59 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u78JVtCW032425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Aug 2016 15:31:56 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Justin Richer 
In-Reply-To: <20160804185427.B0844B80BDA@rfc-editor.org>
Date: Mon, 8 Aug 2016 15:31:54 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <15DA03DB-2B5F-4775-8857-C9BFC65087BC@mit.edu>
References: <20160804185427.B0844B80BDA@rfc-editor.org>
To: RFC Errata System 
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsUixCmqrWtwb0W4wecLKhYrJ+1gt1i68x6r RcPOfIuTb1+xWTTt/8pmMX3vNXYHNo+13VfZPHbOusvusXjTfjaPJUt+Mnks//qAxaOh7Rhr AFsUl01Kak5mWWqRvl0CV0bP7gtsBQsFKs79u87UwPiTp4uRk0NCwETi58Qe5i5GLg4hgTYm iQ9fvzFBOBsYJQ6e2coO4Txgkvh5/zILSAuzgLrEn3mXmEFsXgE9iU3r3wJ1cHAICzhJ3H9Q AxJmE1CVmL6mBSzMKWAh0T5fCyTMIqAiMXdNPyvISGaBL4wS5zZeY4QYqS2xbOFrqJFWErMm LgKLCwmYS9xfd58VxBYRMJQ4uOgtO8TVshJPTi5imcAoMAvJRbOQXDQLydgFjMyrGGVTcqt0 cxMzc4pTk3WLkxPz8lKLdM31cjNL9FJTSjcxgsKe3UVlB2N3j/chRgEORiUe3oqlK8KFWBPL iitzDzFKcjApifLKTwUK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuGNuAqU401JrKxKLcqHSUlz sCiJ827/1h4uJJCeWJKanZpakFoEk5Xh4FCS4L10B6hRsCg1PbUiLTOnBCHNxMEJMpwHaPhD kBre4oLE3OLMdIj8KUZFKXHezSAJAZBERmkeXC8oLSW8PWz6ilEc6BVhXq27QFU8wJQG1/0K aDAT0OAkVbDBJYkIKakGRvnABfOyAlZ2zGN4yVsSIX3+S5/Ng9z1IZxm3gn7TwadrEl5M+0n z0XNtU0/TlTnmHy4E5SVdcaK//wnrVAjk6iPZzUDEs6YPHi04Znb14ynq2Yav/TObeP+GKd5 9uzWNVkHuL7m2Cxe6flwm+vm0HcKXW9XrF6yoakj7PncmMn/MyLyxOt2SSuxFGckGmoxFxUn AgAhuFYHJgMAAA==
Archived-At: 
Cc: Derek Atkins , "" 
Subject: Re: [OAUTH-WG] [Editorial Errata Reported] RFC7662 (4764)
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, 08 Aug 2016 19:32:10 -0000

Yes, this is a valid errata, a result of copy and paste errors for the =
IANA section from RFC7591.

 =E2=80=94 Justin

> On Aug 4, 2016, at 2:54 PM, RFC Errata System =
 wrote:
>=20
> The following errata report has been submitted for RFC7662,
> "OAuth 2.0 Token Introspection".
>=20
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D7662&eid=3D4764
>=20
> --------------------------------------
> Type: Editorial
> Reported by: Brian Campbell 
>=20
> Section: 3.1
>=20
> Original Text
> -------------
> OAuth registration client metadata names and descriptions are
> registered by
>=20
> Corrected Text
> --------------
> OAuth token introspection response parameters are registered by
>=20
> Notes
> -----
> The original text erroneously mentions registration of client metadata =
names, however, this RFC 7662 is about about token introspection and =
this section is about registration of token introspection response =
parameters (client metadata name registration is RFC 7591).
>=20
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.=20
>=20
> --------------------------------------
> RFC7662 (draft-ietf-oauth-introspection-11)
> --------------------------------------
> Title               : OAuth 2.0 Token Introspection
> Publication Date    : October 2015
> Author(s)           : J. Richer, Ed.
> Category            : PROPOSED STANDARD
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Aug 11 15:16:24 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A862B12D1DD for ; Thu, 11 Aug 2016 15:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 bPcUK-H6Ux7J for ; Thu, 11 Aug 2016 15:16:21 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 E4BF712D0AA for ; Thu, 11 Aug 2016 15:16:20 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id q128so2379606wma.1 for ; Thu, 11 Aug 2016 15:16:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=TPzN+3mCUQNMgpf5ZbmmDsuGS5Tp5BlTomZUEZYdwMI=; b=Cd+P2EoX96BZ6oG3kKWFrvSLxAXIRXi6t4JgTHSECH0V4NjYEGGkdf2wrscG9lhxJL WgLIm9WETlCJY3BSuzV2DbT8qBBxsjU05G+aBxAEiqNH1vitOvfwkdl7MsByNEwH57kd 4+z+K75nP8pcL5tgPzNsh8pW4jFYBUCbRVBiLSwnAj4CcOQkIXJ5vYFuVthNwE4j3R2E Z5NxCcmc/E6/xS9eQdtptkvQSLF/hNIfTBh9vhEJ6Q9+IWwKHaXUhUmOzBIAIOarfwhA mR8v6Gll/65uTEfmrAIb7DQl2sWw3FhlhZYfs5Nv1qNwAGNM89hRqNb9xQ2IYdK2X53h Hf4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=TPzN+3mCUQNMgpf5ZbmmDsuGS5Tp5BlTomZUEZYdwMI=; b=E33foLIx2YloByvRDREXqUIUXcDs8F1VCAyrPtOxN/M8OxDo8fT4MX6mQCf9yBkkgI ftlMsa+GpLR1W9bv51eE6IZ+TNMHHChr1/8PgtmaZlpWhfChzIz1liC6TnJNrEWyYY0y gmzptb62nshg2HbVmbWp/NpbQtyWJ0m1uVoR6zy85hlX7wVJ5Soj6mIWW6irv4FRRx/T UmQ1/T+vV6MeumZuVDQ53Uc87wcB/4LQBTGQjXMviUfxh6qEM3dSqjfDGCVhOlxLOiGg GSwWPxKDSZhobc1JWozz7qoVRa21+KZ8sgtNfJhio4+oSQQtGWLsGaiu6jcFyyPPh1gL B6lg==
X-Gm-Message-State: AEkoouufrhkwabpfwzuZMYp1DCeLLgubUnlQzF8ue2GsyAcJh8eGduUEolUCslJ359bX6A==
X-Received: by 10.194.123.228 with SMTP id md4mr11470778wjb.91.1470953779197;  Thu, 11 Aug 2016 15:16:19 -0700 (PDT)
Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id va3sm4624536wjb.18.2016.08.11.15.16.17 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Aug 2016 15:16:18 -0700 (PDT)
To: "oauth@ietf.org" 
From: Sergey Beryozkin 
Message-ID: <8472e581-1382-a364-a232-07ce6eeb0115@gmail.com>
Date: Thu, 11 Aug 2016 23:16:01 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [OAUTH-WG] JWS JWT Access Tokens and resource audiences
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, 11 Aug 2016 22:16:22 -0000

Hi All

Awhile back I was asking why would self-contained JWS JWT access tokens 
would be used (as opposed to JWE JWTs), my concern was that anyone with 
a JWT library can read this token's content - but as I was explained 
that should not be a problem if such a JWS JWT token contains 
non-sensitive information. Besides, in some cases, it gives RS an option 
to validate this JWS JWT locally, without having to make a remote 
validation call.

So I've started experimenting and the immediate question I have is this 
one: which claim should one use to represent a resource server audience 
to get the most inter-operable RS level validation logic ?

For example, a given RS may talk to different 3rd party authorization 
servers, say AS1 (vendor1) and AS2 (vendor2), and either AS1 or AS2 JWS 
JWT tokens that this RS validates locally should ideally use the same 
claim to represent a resource audience. RS validation logic is written 
independently (without using AS1 or AS2 aware validation libraries).

We do expect such requirements coming in our deployments. AS1 & 
independent validation logic is already in use. Just a matter of time 
before AS2 is introduced.

So JWT has a standard 'aud' claim - but I believe this should be a 
'clientId' of the client a token is issued to, similarly to the way the 
'aud' is treated in IdToken.

So I've prototyped the code where JWT has these claims:

"aud" = clientId
"resource" = 'http://myResourceServer'

where 'resource' is borrowed from OAuth2 Resource Indicators draft and 
represent a specific RS target address, the resource server audience.

Am I on the right path ? How would others do it when facing a task of 
including a resource audience in a self-contained JWS JWT access token ?

Many thanks, Sergey


From nobody Thu Aug 11 15:24:50 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B026C12D594 for ; Thu, 11 Aug 2016 15:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O33g1gwp3cLQ for ; Thu, 11 Aug 2016 15:24:48 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04E4712D605 for ; Thu, 11 Aug 2016 15:24:47 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id v123so9861064qkh.2 for ; Thu, 11 Aug 2016 15:24:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iN5/YKE7hks9k1poB8Eyi/H560+/TYqU3a/QsM2pbVc=; b=i9h44pGZjkqgj9Ig3jEVdkX6RM00hZsp2wpki+aZ3U/REVJLX0hMdA5jdHhCTiU4z5 ioiqGd0j0YjRd3nYG7BOOGk+uFwMImrh/wPuZjC2bG9Grvg79srZGofc9tAO3cj1fQWM veskc8s2C1iul7kno1vaCbSVnMFs3Adbi+G3taFG17SfIEguJUrnqsKoSvj/UogM8MAg YMDGQZ7jGlORq+Kw8U0IGuNF4c9D1w/TAYUbWFO73ADoLsxf5nZkLJstA+PIL2SnL/D8 A80LFbq2HncGT3d42FO/jIP1RMBIeGWFE5x0ivpxqI6UuZ4g2DUkOdrpX3qLCJqfWe0j rUVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iN5/YKE7hks9k1poB8Eyi/H560+/TYqU3a/QsM2pbVc=; b=PU1kF3EKuXpm+nvyX8Qx/oVd5t4xd7x45BM+UcD6rmQEpSP9ZCLtU1ej7WYPYyv01X JisufEUU3AFxReTqdr5EP/qsWIQUk1zXOvWxK9lD9AMSoVj3mirqD6b0EsS6oi0EnoTG mrhpNOxGkTLHVc6M1V3B1iLFC9NyM/Ionjg9P9DlGmSYf3z/uRp/+gODi+HHH45mgGo2 Tsnsbwizl/HHZj5c4U7kBGqge7II1viS59grt0NI515iFHr8NkeuzfIIicwj4sT5y+9P PI+V/F6/6P0ANW8zl8QjcN6aP74PcUQryjiOZ9JoVFhNG8u/E0bmCyG3IaTl2GZr3CaF uyng==
X-Gm-Message-State: AEkooutIVOEfPp7LAiOJHQGiqtd9gDEYKUYHvzbGrbKjZ10qETbaPy/PpXaS1v1+M+3i35xH
X-Received: by 10.55.162.67 with SMTP id l64mr13913419qke.106.1470954287005; Thu, 11 Aug 2016 15:24:47 -0700 (PDT)
Received: from [192.168.8.100] ([181.201.74.47]) by smtp.gmail.com with ESMTPSA id 50sm2722333qts.11.2016.08.11.15.24.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Aug 2016 15:24:46 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: <8472e581-1382-a364-a232-07ce6eeb0115@gmail.com>
Date: Thu, 11 Aug 2016 18:24:43 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <852DC4F5-B9A0-4402-8550-6AB725546C63@ve7jtb.com>
References: <8472e581-1382-a364-a232-07ce6eeb0115@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] JWS JWT Access Tokens and resource audiences
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, 11 Aug 2016 22:24:50 -0000

I think most people put the a resource URI in the aud. =20

Connect uses the client ID as that is bit more stable than trying to use =
a redirect URI when there could be multiple ones.
Given that a resource server doesn=E2=80=99t typically have a client_id =
the resource uri make a reasonable value.

You could put it in resource if you like, but that is probably not what =
others are doing.

It may be time for a interoperable JWT access token profile of some =
sort.  We keep getting close with some of the PoP stuff but only specify =
parts.

John B.
> On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin  =
wrote:
>=20
> Hi All
>=20
> Awhile back I was asking why would self-contained JWS JWT access =
tokens would be used (as opposed to JWE JWTs), my concern was that =
anyone with a JWT library can read this token's content - but as I was =
explained that should not be a problem if such a JWS JWT token contains =
non-sensitive information. Besides, in some cases, it gives RS an option =
to validate this JWS JWT locally, without having to make a remote =
validation call.
>=20
> So I've started experimenting and the immediate question I have is =
this one: which claim should one use to represent a resource server =
audience to get the most inter-operable RS level validation logic ?
>=20
> For example, a given RS may talk to different 3rd party authorization =
servers, say AS1 (vendor1) and AS2 (vendor2), and either AS1 or AS2 JWS =
JWT tokens that this RS validates locally should ideally use the same =
claim to represent a resource audience. RS validation logic is written =
independently (without using AS1 or AS2 aware validation libraries).
>=20
> We do expect such requirements coming in our deployments. AS1 & =
independent validation logic is already in use. Just a matter of time =
before AS2 is introduced.
>=20
> So JWT has a standard 'aud' claim - but I believe this should be a =
'clientId' of the client a token is issued to, similarly to the way the =
'aud' is treated in IdToken.
>=20
> So I've prototyped the code where JWT has these claims:
>=20
> "aud" =3D clientId
> "resource" =3D 'http://myResourceServer'
>=20
> where 'resource' is borrowed from OAuth2 Resource Indicators draft and =
represent a specific RS target address, the resource server audience.
>=20
> Am I on the right path ? How would others do it when facing a task of =
including a resource audience in a self-contained JWS JWT access token ?
>=20
> Many thanks, Sergey
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Thu Aug 11 15:31:02 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E9E12D82C for ; Thu, 11 Aug 2016 15:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 UWYqGcXtSAet for ; Thu, 11 Aug 2016 15:31:00 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64A812D605 for ; Thu, 11 Aug 2016 15:30:59 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id o80so19950890wme.1 for ; Thu, 11 Aug 2016 15:30:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ESSliqjx7CR4GL2YOs2UvIMZjcsBQ9jnp2orQIzrFgM=; b=xnJfD7mgncntDBlEROTFnNkqTLKyb5HXvujS9Cs6BO5ltoEKLrbME6S0rEbCo0t2Dl GIkoYKWqKRjtd4QIhIYMocBjQSwSAKCge+MHC5RPlcUmUj4dOSrTri880uwGPUiw0H+K n+htQzbJO19zkE5E9gmtkrDOyVyGI8ZKN3KFCFs4IXuVzQddhPC+C+vTrK36uxVlAUyW PnGtbeMCznrZ9d2OBYLJF5KCapUeiFphK8EZ0q+LHhrKPm53K7hFNG1yj+WucXMghQ2H +kpeNhwdAsbdRSsf6aqxK9vA27WxQebg8J5J0z60+B5ckb7wjy9MS3weaVX9LlusryUc Pnng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ESSliqjx7CR4GL2YOs2UvIMZjcsBQ9jnp2orQIzrFgM=; b=HC0ujdf+S4Y27aACNGqRUSBGdpZAvHEt2aOPdW5M86bL5tr7vY74hPFlqGCzcnp86n mKLudQZgawj/Aow7fQodDf6azps1UZMx5hWU47gdeKPAgfEIzSyvBCiEBWDK07SHS8Y5 xI8wXo/Sjv1mn7GTpZNxKofXxgM69Cysoe7J0zbNemd7/PJt2EQFh5HEfTkxs9bjk1rj Z9w9OG1gMdGLaIV24VZ7wLKdiFoO9QczBnjpp1FneGsRUxd07ikCM7U7mTMCk6ZyqzMm 6btXLx4jJpjTJ1cwXeVa+ZWzmt5SUlnBLSSVMBvM2yhsSU1CY+T8SDpPjpJoizulkOLJ dekw==
X-Gm-Message-State: AEkoouvz9Cq5CGto3fYGkdUNb7xRlV4bEpEyDkaVtCv21/BYvmrkkD8c4uREXfmAoFvzyA==
X-Received: by 10.194.107.33 with SMTP id gz1mr14646194wjb.178.1470954658123;  Thu, 11 Aug 2016 15:30:58 -0700 (PDT)
Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id a203sm2117869wma.0.2016.08.11.15.30.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Aug 2016 15:30:57 -0700 (PDT)
To: John Bradley 
References: <8472e581-1382-a364-a232-07ce6eeb0115@gmail.com> <852DC4F5-B9A0-4402-8550-6AB725546C63@ve7jtb.com>
From: Sergey Beryozkin 
Message-ID: <9912591c-ce6c-b13c-e9f2-f0fb66b557d8@gmail.com>
Date: Thu, 11 Aug 2016 23:30:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <852DC4F5-B9A0-4402-8550-6AB725546C63@ve7jtb.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] JWS JWT Access Tokens and resource audiences
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, 11 Aug 2016 22:31:01 -0000

Hi John
On 11/08/16 23:24, John Bradley wrote:
> I think most people put the a resource URI in the aud.
>
> Connect uses the client ID as that is bit more stable than trying to use a redirect URI when there could be multiple ones.
> Given that a resource server doesn’t typically have a client_id the resource uri make a reasonable value.
>
> You could put it in resource if you like, but that is probably not what others are doing.
I was suspecting I might be on my own here yes :-)

>
> It may be time for a interoperable JWT access token profile of some sort.

+1

> We keep getting close with some of the PoP stuff but only specify parts.

Thanks, Sergey

>
> John B.
>> On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin  wrote:
>>
>> Hi All
>>
>> Awhile back I was asking why would self-contained JWS JWT access tokens would be used (as opposed to JWE JWTs), my concern was that anyone with a JWT library can read this token's content - but as I was explained that should not be a problem if such a JWS JWT token contains non-sensitive information. Besides, in some cases, it gives RS an option to validate this JWS JWT locally, without having to make a remote validation call.
>>
>> So I've started experimenting and the immediate question I have is this one: which claim should one use to represent a resource server audience to get the most inter-operable RS level validation logic ?
>>
>> For example, a given RS may talk to different 3rd party authorization servers, say AS1 (vendor1) and AS2 (vendor2), and either AS1 or AS2 JWS JWT tokens that this RS validates locally should ideally use the same claim to represent a resource audience. RS validation logic is written independently (without using AS1 or AS2 aware validation libraries).
>>
>> We do expect such requirements coming in our deployments. AS1 & independent validation logic is already in use. Just a matter of time before AS2 is introduced.
>>
>> So JWT has a standard 'aud' claim - but I believe this should be a 'clientId' of the client a token is issued to, similarly to the way the 'aud' is treated in IdToken.
>>
>> So I've prototyped the code where JWT has these claims:
>>
>> "aud" = clientId
>> "resource" = 'http://myResourceServer'
>>
>> where 'resource' is borrowed from OAuth2 Resource Indicators draft and represent a specific RS target address, the resource server audience.
>>
>> Am I on the right path ? How would others do it when facing a task of including a resource audience in a self-contained JWS JWT access token ?
>>
>> Many thanks, Sergey
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>


From nobody Thu Aug 11 15:35:52 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFE312D0AA for ; Thu, 11 Aug 2016 15:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 dySXFU3DFOyq for ; Thu, 11 Aug 2016 15:35:49 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c: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 AD80012B047 for ; Thu, 11 Aug 2016 15:35:49 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id q128so2469696wma.1 for ; Thu, 11 Aug 2016 15:35:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=WEDImadfhLIs7uGPlCuYW9cyHik9Rw7bA1brB+xvGnE=; b=y3hXyMDTxiG1Uhgm+Ku81+PlOZ9BmsmoUPosw0nhL7wSpSCWDXydH3eyAGYiTsShiq DHsvheeyUQJIIvFnCmBfTa9zYTZZVX8zbEYGsaAocxG1fclOGtAu0OX4G4Fm6VEe/LIf k12fZDu7DV2ghPz+v0j6gWJ5jUST0rxJ4KzdDPiJvG0Vl6JFKhtim/JEEIEDQ0DtW+LS AhdsPRQN1iC49KfT8qkVH/zQPHvHr+prJTF1SxvD65ay2G5CYXqcNlICGW6bSFbfRDJ1 Ibe/9hbZOhs/fgHP2J++27c6Ya/giPoFOxYc7cPucYXBNg+HlPApK0ZrkHfNvP0Gq/e0 lN0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=WEDImadfhLIs7uGPlCuYW9cyHik9Rw7bA1brB+xvGnE=; b=dVqaMWi9txVzKaQuMa0Q15ph20P5DiGIEnONwzwhgNaXhbPhKnJYteciiZ5Hc5u5t4 vY7R/bXselm/Ou5QRA0gRW264XzsB5Wj2uI5NrHaMYwYxPq6EuNU6NSkwSc3ZwP3JQCZ lUJ7ERcJXTf4VBH1cmLTBkhuGvLtrdVP7dXGrVqVqQl52Ru1qaEV3TOZNslNQ5xk09yL Ena3XVWSA+JKpGG0r6BVo4V8fTLEq7LzSJ6RULfu19oTBx0q6cl6gn9vwrvTGFcBgh0X O1FwgpzBpCxdE+W4Gg86ZLtC3yYM0JBB2OcYLKMCqchgevTEOZ+Y9k3BY7nb9W+Uw/Ro 1tZQ==
X-Gm-Message-State: AEkoousSVqWI257YqBYX33taTA9wIqudkvS7KBcbDfAQs7F0igoRvEBEIV4YMFsaAvDIfw==
X-Received: by 10.28.193.10 with SMTP id r10mr12019483wmf.49.1470954947924; Thu, 11 Aug 2016 15:35:47 -0700 (PDT)
Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id a184sm1892333wmh.1.2016.08.11.15.35.46 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Aug 2016 15:35:47 -0700 (PDT)
From: Sergey Beryozkin 
To: "oauth@ietf.org" 
Message-ID: <231ad20a-e508-c763-4972-375fefd65fb0@gmail.com>
Date: Thu, 11 Aug 2016 23:35:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [OAUTH-WG] How to participate in OAuth2 IETF meetings
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, 11 Aug 2016 22:35:51 -0000

Hi All

Who can participate in OAuth2 IETF meetings/workshops ?
I've checked the meeting archives, apparently the 'Newcomers' can be 
there but how formal the process is and how OAuth2-'qualified' the 
newcomers should be ?

I'm interested in talking to other OAuth2 implementers f2f and myself 
and my other colleagues might also provide some input to the 
standardization effort.

Are the rules for OIDC & JOSE workshops different (I can ask on specific 
lists for more details if yes)

We might be able to join sometimes depending on the locality, times, and 
other constraints.



Cheers, Sergey


From nobody Thu Aug 11 15:43:26 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DC512D84D for ; Thu, 11 Aug 2016 15:43:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRZ4iVVe4O5O for ; Thu, 11 Aug 2016 15:43:24 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FC012D0AA for ; Thu, 11 Aug 2016 15:43:23 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id p186so10322763qkd.1 for ; Thu, 11 Aug 2016 15:43:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CUUJQwV8kjoBMdSLkFDEvSKjtTM16+yi6juMEdxJqwA=; b=UhnFJe0+hdQ3SUYdjjUYlnaZzxWTn2DJsHrDIuUZ8MQnCtDb0fN7BkGMJiCpcEjkZc m4Avoc2eJ4AHqb5xI8WlNmX35e8PA6AS7BKanmFeyijy1ljiSCclMYw2QD7jT00VIlfU lpjVPIO/uqoHYooE7Zm79RCeddrn2Z2kaSFeBMpiTWG3hlQMsGj/ixUt2DEXcW6Boedk vjc+/3U0TpuNZi9eOKiT7/Wxb7VNcXh0jI/d15deqsnzyKeEv6jsJk3kA2oEH2/+STyq auQkbeSQVJiWCx/9wSY+/qu2PzMx/pu8nUXy1cceP5jyanEc4GKAybMpl5NmNmWMelEi fPCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CUUJQwV8kjoBMdSLkFDEvSKjtTM16+yi6juMEdxJqwA=; b=AAyrjchCO2pS/jkQ5dWR8fPsrwimcOEtsRaIqIBXWyinY5hYXMDaJEbElelJiLqqxT BaGNINaetFza78Ium6yJquh1zSE/XmkMgQmJrgsLiLFTQs8sKPSoXFvRE4IlZjNv3PDe oDYRw7Qcqhmtlb3Eg3NlRpxFzfLaM1HKimuxbBIMJNgeQAn250oEW4lP22CaxEyiZeyr M3AKTYPou4EfQ1I8bYYi7jezw0uxePNYY0n3WgWSSVZx3z5u3bhxIh8Eb+HWM6092QaM eY4ipTdJklkwEQO1fGTlKoOIiwrCYwaZG6fdSgg7A1cX8+OhkjY+f85DbPuS7XNozvCO jdEA==
X-Gm-Message-State: AEkoouu+y9fD03Q9RjL1q+oOc/FajmgiwoyXPRQwoFH7j49qS2zrSwG52HOX4JzHJy/fAqzr
X-Received: by 10.55.102.75 with SMTP id a72mr13907187qkc.20.1470955402843; Thu, 11 Aug 2016 15:43:22 -0700 (PDT)
Received: from [192.168.8.100] ([181.201.74.47]) by smtp.gmail.com with ESMTPSA id r29sm2736564qte.48.2016.08.11.15.43.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Aug 2016 15:43:22 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: <231ad20a-e508-c763-4972-375fefd65fb0@gmail.com>
Date: Thu, 11 Aug 2016 18:43:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <515C7B67-345D-43EA-836D-099FFD9EADCF@ve7jtb.com>
References: <231ad20a-e508-c763-4972-375fefd65fb0@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] How to participate in OAuth2 IETF meetings
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, 11 Aug 2016 22:43:26 -0000

Anyone can attend IETF meetings, and we encourage new people.  We all =
were new at some point.  (I have always been old but am the exception)

We meet 3 times a year.  The meetings are listed at =
https://www.ietf.org/meeting/upcoming.html

There are sometimes interim meetings that are announced on the list.  We =
just had one on Security in Germany.

Often there more informal meetings at IIW =
http://www.internetidentityworkshop.com/ in California twice a year and =
at OpenID workshops.

John B.

> On Aug 11, 2016, at 6:35 PM, Sergey Beryozkin  =
wrote:
>=20
> Hi All
>=20
> Who can participate in OAuth2 IETF meetings/workshops ?
> I've checked the meeting archives, apparently the 'Newcomers' can be =
there but how formal the process is and how OAuth2-'qualified' the =
newcomers should be ?
>=20
> I'm interested in talking to other OAuth2 implementers f2f and myself =
and my other colleagues might also provide some input to the =
standardization effort.
>=20
> Are the rules for OIDC & JOSE workshops different (I can ask on =
specific lists for more details if yes)
>=20
> We might be able to join sometimes depending on the locality, times, =
and other constraints.
>=20
>=20
>=20
> Cheers, Sergey
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From nobody Fri Aug 12 01:34:35 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A1E12B04F for ; Fri, 12 Aug 2016 01:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 T867UrIULIpL for ; Fri, 12 Aug 2016 01:34:31 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c: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 559BD128E19 for ; Fri, 12 Aug 2016 01:34:31 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id o80so17898012wme.1 for ; Fri, 12 Aug 2016 01:34:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=ZUJ8jc/dnXgUPuWGaKVIowXdp+Q996MZcq+o1KsixDo=; b=hK9TSXM5DI5qinp2DqsuEjQG5Xiibo4sGXOoLikUnGKxFR6cddPahlzAfY79v2+wkJ ldD5C5yqh1ahZoncvhlUOUvlHv+L0rR6uGLzMgQkGFPWHGFALWfGSLAc8IEdcdrOWWW6 UA5SMmvebu11+nQwH5KKW4203eTHPUcZhjFmkSnDwuwoSihD5k6KKgaTrGo1rFRTwcG3 Y8qh9LBkTcDgJN64nAfYnKGDl45zM50KvlcOnxA+6E9Qnds8nYV0dGb4TSgsD4dWLs1V 9HVhuU/fnIdhtkDhhDvll+IgBC64Fg98F0vUblmxblgWtCx5eGCxioVaFZqGbFx9maD5 n3zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ZUJ8jc/dnXgUPuWGaKVIowXdp+Q996MZcq+o1KsixDo=; b=T0Nn6H2he0yMUNXN6BOhgKytDYiimoF9eR3NOLfzAEGqEpx128oiFE8ywVFNWsNOGF vlpsXf7P0wUry+fVSBcsbHuBeeKGmngizRo+9fSC9rF3EeUrWFfP4977t7o+vwIqMyi7 Z5bmZ+abzTm6NkzLdAQsOLw9er2LMkgIQPL71m+DudKkQXr3KerXM29DSHnWPWY93pU0 t9aReT41lzyRvCqBmmUKj3T1q2a7XDc8kLNgpBe/kVnJCe7Oq04nUZlpV7bc7y8zCpCL Ah2SIyOItL83w9bX5/6YfjvfFkwvtkuYcRMYehMocnisprHPzeiXgK/2oArt8oZEqTXi 9IPw==
X-Gm-Message-State: AEkoous75gBRmrbHo4yO4ZfGMx6+I5m8EkjPLPVaKqUqaDC6rG7Tlkj10rA/Ghfxyq0WTQ==
X-Received: by 10.28.154.208 with SMTP id c199mr1853273wme.102.1470990869635;  Fri, 12 Aug 2016 01:34:29 -0700 (PDT)
Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id d80sm1461138wmd.14.2016.08.12.01.34.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Aug 2016 01:34:28 -0700 (PDT)
To: John Bradley 
References: <231ad20a-e508-c763-4972-375fefd65fb0@gmail.com> <515C7B67-345D-43EA-836D-099FFD9EADCF@ve7jtb.com>
From: Sergey Beryozkin 
Message-ID: 
Date: Fri, 12 Aug 2016 09:34:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <515C7B67-345D-43EA-836D-099FFD9EADCF@ve7jtb.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] How to participate in OAuth2 IETF meetings
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, 12 Aug 2016 08:34:33 -0000

Hi John

On 11/08/16 23:43, John Bradley wrote:
> Anyone can attend IETF meetings, and we encourage new people.  We all were new at some point.  (I have always been old but am the exception)

Wait and see a newcomer like myself and you may get surprised :-)

>
> We meet 3 times a year.  The meetings are listed at https://www.ietf.org/meeting/upcoming.html
>
> There are sometimes interim meetings that are announced on the list.  We just had one on Security in Germany.
>
> Often there more informal meetings at IIW http://www.internetidentityworkshop.com/ in California twice a year and at OpenID workshops.
>
We'll keep an eye on the upcoming calendar and the list announcements.

Many thanks, Sergey

> John B.
>
>> On Aug 11, 2016, at 6:35 PM, Sergey Beryozkin  wrote:
>>
>> Hi All
>>
>> Who can participate in OAuth2 IETF meetings/workshops ?
>> I've checked the meeting archives, apparently the 'Newcomers' can be there but how formal the process is and how OAuth2-'qualified' the newcomers should be ?
>>
>> I'm interested in talking to other OAuth2 implementers f2f and myself and my other colleagues might also provide some input to the standardization effort.
>>
>> Are the rules for OIDC & JOSE workshops different (I can ask on specific lists for more details if yes)
>>
>> We might be able to join sometimes depending on the locality, times, and other constraints.
>>
>>
>>
>> Cheers, Sergey
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>


From nobody Fri Aug 12 03:13:38 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1591C12D69A for ; Fri, 12 Aug 2016 03:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 b3bhntRYpevr for ; Fri, 12 Aug 2016 03:13:35 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 DA7DE12D13E for ; Fri, 12 Aug 2016 03:13:34 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id q128so19553206wma.1 for ; Fri, 12 Aug 2016 03:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=qlXJ7jtnMF3lIoxiU8N/7xCyU7xdzwcfEaPlWyPxHn8=; b=qG0hSOK/Wkgsb1wXszs05Ki512nOtXCCuUz8d/VMCOUxvWYwpPrshHnOCwCMH7gxwv Eh3ORN80XvIXs4d4S489n/XuWabCJab+gNvt0itZn/Pgo4QMbtdHNgT9x559HfWBzZt2 sGKn3t50SIqzkqVo2iBI8ZDjZYFqV/p0RkqnrmM9Hqq/gpwbetKP4KJfAUIM4ENVKhmw yffV/dAKMJ56w90Z4F57ktDjvWcEoJPQC863RdcOLDRP7CuyxtCyV8HRpI0GIrhhr4hz pPkYM0WWy/Mcj+Q6lOTHlQUo1m80ccS9aliM8hGO5cZfqCcYlLVPb95YyTXQpmAN00Z3 GNEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=qlXJ7jtnMF3lIoxiU8N/7xCyU7xdzwcfEaPlWyPxHn8=; b=mg1aZn2/dzZzKxSK1ZzzynfK2BjLwUN05+ZAwt26DR7uvl2eSs3cTsEaq8wQ2ab9/d 3KcvsMoRwyURuYD9O0JiZPjhLMwQ0zfkB833vhSHt76sxDrCt10aONBzmhkG6vpjWicY ISCY1/RPm/pllDA0kaeLbiZta28qzqNUJY+3Qlo2hSvnTrlGmejRvpW+BnLf8cBg/khx K8mtCDSIFGeRSOP7Uccd7qrMC4QVhum7D6wVORykRzUsckb703XM6xrH+sAR7aNHcDwH zzVJMhkgIPdMkN02RfDl4tMzrn2HM9luppJKRgGgZiCPoQmeSjIhQnZgv/BwKgMUNENR /BWQ==
X-Gm-Message-State: AEkoouuvLB8TOR6CZllkpdQf1k6B2LFccNGIAtHc/uPzS5Ar0M1PdkxLJSRIWEygOOLslA==
X-Received: by 10.28.100.70 with SMTP id y67mr2249047wmb.23.1470996813127; Fri, 12 Aug 2016 03:13:33 -0700 (PDT)
Received: from [192.168.2.7] ([79.97.121.181]) by smtp.googlemail.com with ESMTPSA id a184sm1907158wmh.1.2016.08.12.03.13.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Aug 2016 03:13:32 -0700 (PDT)
To: John Bradley 
References: <8472e581-1382-a364-a232-07ce6eeb0115@gmail.com> <852DC4F5-B9A0-4402-8550-6AB725546C63@ve7jtb.com> <9912591c-ce6c-b13c-e9f2-f0fb66b557d8@gmail.com>
From: Sergey Beryozkin 
Message-ID: <6b6457e2-9cf1-9fdc-25f8-a0ee6be6976e@gmail.com>
Date: Fri, 12 Aug 2016 11:13:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <9912591c-ce6c-b13c-e9f2-f0fb66b557d8@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] JWS JWT Access Tokens and resource audiences
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, 12 Aug 2016 10:13:37 -0000

Hi,


After updating my earlier code (where 'client_id' was set as the 
standard JWT access token 'aud' property) to use 'aud' to represent the 
resource audiences I'm now thinking how to represent a 'client_id' in 
this token.

For now if I'm using a 'client_id' claim, to be consistent with a 
standard token introspection response.

The other thing is how to represent a name of the user who authorized 
the code grant which was exchanged for this token.

Again I'm using a "username" claim, to be consistent with a standard 
token introspection response.

Also thinking, what value if any a 'sub' claim in such a token should 
have. I'm setting it to a unique user identifier (similarly to IdToken).

Any comments are welcome

Sergey

On 11/08/16 23:30, Sergey Beryozkin wrote:
> Hi John
> On 11/08/16 23:24, John Bradley wrote:
>> I think most people put the a resource URI in the aud.
>>
>> Connect uses the client ID as that is bit more stable than trying to
>> use a redirect URI when there could be multiple ones.
>> Given that a resource server doesn’t typically have a client_id the
>> resource uri make a reasonable value.
>>
>> You could put it in resource if you like, but that is probably not
>> what others are doing.
> I was suspecting I might be on my own here yes :-)
>
>>
>> It may be time for a interoperable JWT access token profile of some sort.
>
> +1
>
>> We keep getting close with some of the PoP stuff but only specify parts.
>
> Thanks, Sergey
>
>>
>> John B.
>>> On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin 
>>> wrote:
>>>
>>> Hi All
>>>
>>> Awhile back I was asking why would self-contained JWS JWT access
>>> tokens would be used (as opposed to JWE JWTs), my concern was that
>>> anyone with a JWT library can read this token's content - but as I
>>> was explained that should not be a problem if such a JWS JWT token
>>> contains non-sensitive information. Besides, in some cases, it gives
>>> RS an option to validate this JWS JWT locally, without having to make
>>> a remote validation call.
>>>
>>> So I've started experimenting and the immediate question I have is
>>> this one: which claim should one use to represent a resource server
>>> audience to get the most inter-operable RS level validation logic ?
>>>
>>> For example, a given RS may talk to different 3rd party authorization
>>> servers, say AS1 (vendor1) and AS2 (vendor2), and either AS1 or AS2
>>> JWS JWT tokens that this RS validates locally should ideally use the
>>> same claim to represent a resource audience. RS validation logic is
>>> written independently (without using AS1 or AS2 aware validation
>>> libraries).
>>>
>>> We do expect such requirements coming in our deployments. AS1 &
>>> independent validation logic is already in use. Just a matter of time
>>> before AS2 is introduced.
>>>
>>> So JWT has a standard 'aud' claim - but I believe this should be a
>>> 'clientId' of the client a token is issued to, similarly to the way
>>> the 'aud' is treated in IdToken.
>>>
>>> So I've prototyped the code where JWT has these claims:
>>>
>>> "aud" = clientId
>>> "resource" = 'http://myResourceServer'
>>>
>>> where 'resource' is borrowed from OAuth2 Resource Indicators draft
>>> and represent a specific RS target address, the resource server
>>> audience.
>>>
>>> Am I on the right path ? How would others do it when facing a task of
>>> including a resource audience in a self-contained JWS JWT access token ?
>>>
>>> Many thanks, Sergey
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>


From nobody Fri Aug 12 15:31:20 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE7812D744 for ; Fri, 12 Aug 2016 15:31:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W39HJ65kd_ct for ; Fri, 12 Aug 2016 15:31:16 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 CEE0212B042 for ; Fri, 12 Aug 2016 15:31:15 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id f6so26317029ith.0 for ; Fri, 12 Aug 2016 15:31:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NRAvFfdu+AOVSONS5Ij0KyVihFGVq6gP8Hkf6E0Ms/E=; b=NzoTNqiSeGEAswsLXkKnDBZqotoHN2D+tb2pSNcwyuHO3w7jeBVwSdwuNgF6HcBGtg o7EF8dS3Mhoijc/UTimlC6zrzWxSxHM2nVT5oI14Cg0PdltZ2aR9FHfO6l/A3gGlOibg IjRGuI7xVCb6Q4XMWcFGkVJm864T4e8eE+Zjs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NRAvFfdu+AOVSONS5Ij0KyVihFGVq6gP8Hkf6E0Ms/E=; b=A5FEzvMQVjquedAV9IykyeEGqdVn7Q0ba15tAzHyyGmztOcHtIzJYw6k98OgF7M8kK jGMmU+64bwpMuYtn8AHUaCgun5PP+5CSOZMehHQpjEQbpYBC7VsyxUKfACYoEbeqk6Ze euAbcuEKWoqs7F2D5iMrR3BztzRh5k1Y/orTKoTxlnnneGXiEqH2m02nQGUt+tYc53v9 WfF3GYbL62DsPZae/XRz7wAu/BqLomGHOA9vttxO/u2pdpof2R4GsKDD8stoynT7HTBV 3YvkPfpBOsUFzM1VPw/gpawFlTfTNRNKJuALjGYkuKyrW+5Q3O73Rhtut24rGVypMDxd OajQ==
X-Gm-Message-State: AEkoouuOrTctL+rFezX9c1dBPh/epftE/d90Y8HvUIobDd1bwX/yEvgUdTgzARhrNjNzVHnA1Vn82DhoCqxVct2Y
X-Received: by 10.36.34.145 with SMTP id o139mr1487556ito.11.1471041075079; Fri, 12 Aug 2016 15:31:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.123.14 with HTTP; Fri, 12 Aug 2016 15:30:44 -0700 (PDT)
In-Reply-To: <6b6457e2-9cf1-9fdc-25f8-a0ee6be6976e@gmail.com>
References: <8472e581-1382-a364-a232-07ce6eeb0115@gmail.com> <852DC4F5-B9A0-4402-8550-6AB725546C63@ve7jtb.com> <9912591c-ce6c-b13c-e9f2-f0fb66b557d8@gmail.com> <6b6457e2-9cf1-9fdc-25f8-a0ee6be6976e@gmail.com>
From: Brian Campbell 
Date: Fri, 12 Aug 2016 16:30:44 -0600
Message-ID: 
To: Sergey Beryozkin 
Content-Type: multipart/alternative; boundary=001a11406670bb0d710539e770e7
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] JWS JWT Access Tokens and resource audiences
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, 12 Aug 2016 22:31:18 -0000

--001a11406670bb0d710539e770e7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yeah, the client typically isn't the/an audience of an access token. The AT
is opaque to the client and the client never processes or validates it. So
aud would have the resource(s) and something else could carry the client
id.

FWIW, token exchange is looking to define and register "cid" as a JWT claim
for the client identifier:
https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05#section-4.3

On Fri, Aug 12, 2016 at 4:13 AM, Sergey Beryozkin 
wrote:

> Hi,
>
>
> After updating my earlier code (where 'client_id' was set as the standard
> JWT access token 'aud' property) to use 'aud' to represent the resource
> audiences I'm now thinking how to represent a 'client_id' in this token.
>
> For now if I'm using a 'client_id' claim, to be consistent with a standar=
d
> token introspection response.
>
> The other thing is how to represent a name of the user who authorized the
> code grant which was exchanged for this token.
>
> Again I'm using a "username" claim, to be consistent with a standard toke=
n
> introspection response.
>
> Also thinking, what value if any a 'sub' claim in such a token should
> have. I'm setting it to a unique user identifier (similarly to IdToken).
>
> Any comments are welcome
>
> Sergey
>
>
> On 11/08/16 23:30, Sergey Beryozkin wrote:
>
>> Hi John
>> On 11/08/16 23:24, John Bradley wrote:
>>
>>> I think most people put the a resource URI in the aud.
>>>
>>> Connect uses the client ID as that is bit more stable than trying to
>>> use a redirect URI when there could be multiple ones.
>>> Given that a resource server doesn=E2=80=99t typically have a client_id=
 the
>>> resource uri make a reasonable value.
>>>
>>> You could put it in resource if you like, but that is probably not
>>> what others are doing.
>>>
>> I was suspecting I might be on my own here yes :-)
>>
>>
>>> It may be time for a interoperable JWT access token profile of some sor=
t.
>>>
>>
>> +1
>>
>> We keep getting close with some of the PoP stuff but only specify parts.
>>>
>>
>> Thanks, Sergey
>>
>>
>>> John B.
>>>
>>>> On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin 
>>>> wrote:
>>>>
>>>> Hi All
>>>>
>>>> Awhile back I was asking why would self-contained JWS JWT access
>>>> tokens would be used (as opposed to JWE JWTs), my concern was that
>>>> anyone with a JWT library can read this token's content - but as I
>>>> was explained that should not be a problem if such a JWS JWT token
>>>> contains non-sensitive information. Besides, in some cases, it gives
>>>> RS an option to validate this JWS JWT locally, without having to make
>>>> a remote validation call.
>>>>
>>>> So I've started experimenting and the immediate question I have is
>>>> this one: which claim should one use to represent a resource server
>>>> audience to get the most inter-operable RS level validation logic ?
>>>>
>>>> For example, a given RS may talk to different 3rd party authorization
>>>> servers, say AS1 (vendor1) and AS2 (vendor2), and either AS1 or AS2
>>>> JWS JWT tokens that this RS validates locally should ideally use the
>>>> same claim to represent a resource audience. RS validation logic is
>>>> written independently (without using AS1 or AS2 aware validation
>>>> libraries).
>>>>
>>>> We do expect such requirements coming in our deployments. AS1 &
>>>> independent validation logic is already in use. Just a matter of time
>>>> before AS2 is introduced.
>>>>
>>>> So JWT has a standard 'aud' claim - but I believe this should be a
>>>> 'clientId' of the client a token is issued to, similarly to the way
>>>> the 'aud' is treated in IdToken.
>>>>
>>>> So I've prototyped the code where JWT has these claims:
>>>>
>>>> "aud" =3D clientId
>>>> "resource" =3D 'http://myResourceServer'
>>>>
>>>> where 'resource' is borrowed from OAuth2 Resource Indicators draft
>>>> and represent a specific RS target address, the resource server
>>>> audience.
>>>>
>>>> Am I on the right path ? How would others do it when facing a task of
>>>> including a resource audience in a self-contained JWS JWT access token=
 ?
>>>>
>>>> Many thanks, Sergey
>>>>
>>>> _______________________________________________
>>>> 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
>

--001a11406670bb0d710539e770e7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Yeah, the client typically isn't the/an audience =
of an access token. The AT is opaque to the client and the client never pro=
cesses or validates it. So aud would have the resource(s) and something els=
e could carry the client id. 

FWIW, token exchange is looking =
to define and register "cid" as a JWT claim for the client identi=
fier: https://tools.ietf.org/html/draft-ietf-oauth-token-exchan=
ge-05#section-4.3

On Fri, Aug 12, 2016 at 4:13 AM, Sergey Beryozkin <sber=
yozkin@gmail.com> wrote:
Hi=
,





After updating my earlier code (where 'client_id' was set as the st=
andard JWT access token 'aud' property) to use 'aud' to rep=
resent the resource audiences I'm now thinking how to represent a '=
client_id' in this token.



For now if I'm using a 'client_id' claim, to be consistent with=
 a standard token introspection response.



The other thing is how to represent a name of the user who authorized the c=
ode grant which was exchanged for this token.



Again I'm using a "username" claim, to be consistent with a s=
tandard token introspection response.



Also thinking, what value if any a 'sub' claim in such a token shou=
ld have. I'm setting it to a unique user identifier (similarly to IdTok=
en).



Any comments are welcome



Sergey




On 11/08/16 23:30, Sergey Beryozkin wrote:



Hi John

On 11/08/16 23:24, John Bradley wrote:



I think most people put the a resource URI in the aud.



Connect uses the client ID as that is bit more stable than trying to

use a redirect URI when there could be multiple ones.

Given that a resource server doesn=E2=80=99t typically have a client_id the=


resource uri make a reasonable value.



You could put it in resource if you like, but that is probably not

what others are doing.



I was suspecting I might be on my own here yes :-)







It may be time for a interoperable JWT access token profile of some sort.




+1





We keep getting close with some of the PoP stuff but only specify parts.




Thanks, Sergey







John B.



On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin <sberyozkin@gmail.com>

wrote:



Hi All



Awhile back I was asking why would self-contained JWS JWT access

tokens would be used (as opposed to JWE JWTs), my concern was that

anyone with a JWT library can read this token's content - but as I

was explained that should not be a problem if such a JWS JWT token

contains non-sensitive information. Besides, in some cases, it gives

RS an option to validate this JWS JWT locally, without having to make

a remote validation call.



So I've started experimenting and the immediate question I have is

this one: which claim should one use to represent a resource server

audience to get the most inter-operable RS level validation logic ?



For example, a given RS may talk to different 3rd party authorization

servers, say AS1 (vendor1) and AS2 (vendor2), and either AS1 or AS2

JWS JWT tokens that this RS validates locally should ideally use the

same claim to represent a resource audience. RS validation logic is

written independently (without using AS1 or AS2 aware validation

libraries).



We do expect such requirements coming in our deployments. AS1 &

independent validation logic is already in use. Just a matter of time

before AS2 is introduced.



So JWT has a standard 'aud' claim - but I believe this should be a<=
br>
'clientId' of the client a token is issued to, similarly to the way=


the 'aud' is treated in IdToken.



So I've prototyped the code where JWT has these claims:



"aud" =3D clientId

"resource" =3D 'http://myResourceServer'



where 'resource' is borrowed from OAuth2 Resource Indicators draft<=
br>
and represent a specific RS target address, the resource server

audience.



Am I on the right path ? How would others do it when facing a task of

including a resource audience in a self-contained JWS JWT access token ?


Many thanks, Sergey



_______________________________________________

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





--001a11406670bb0d710539e770e7--


From nobody Tue Aug 16 05:17:35 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AE512D79F for ; Tue, 16 Aug 2016 05:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 TUTNnFXo_gUo for ; Tue, 16 Aug 2016 05:17:32 -0700 (PDT)
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 351D512D809 for ; Tue, 16 Aug 2016 05:09:55 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id o80so163104495wme.1 for ; Tue, 16 Aug 2016 05:09:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=fp8x1AUSii1BJoZ1Gl9ZSxo012F4nrseCxkMcfMtOn4=; b=c9FYqszJSG+V+a+jfU3+AkAq4ymYaohVXh5bv4JmZisbFO4JTTxAcAblDZ6aXz64W5 3/ZoW04b5pD+XfG8ClbC0n/dXcRxaKTJ47JXB/irDo02oolDQuqXR/IUHQIlDcC3+Ytk Aq/a3VD9AkT3kGJs11TFX5t4r8SLOhVnnBO9dyTVoU1lOBIDV/Tsj9WzOFQ/Qfk6oqGB QjBu3rBj/Gn5znVQ+tHaLRlyem4tWkISfrsIG7c58NNLE7V9+BmBHVIRlcLSQLetgqDU 516H6DbX39EHqqb1zprBscQRWgYywK+UyVeBuC1rLtVstoOZsaOa1LW42OgVOTwGbrT6 1RCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fp8x1AUSii1BJoZ1Gl9ZSxo012F4nrseCxkMcfMtOn4=; b=kbMuJ24Ie9NZrqEasb0kptUTjVAXAJwj1xCHT2dM5DHC5dp4Tcof1XnNw1JMlrho11 fooUMn9AhTNfxLfCp7B+5WP2Z0XPtcFNd4d7EjRItNBpXkckRSXd6SP7iQa/G5QyfnAG ZlIVGmF0eCdfWl3pJBGAxeY9PExgtnYvW1JIc7gy7bi6csyDX0kjkaWbpu3wDfFZSiS+ SSJrFsGLNHZAFYd5CguO8eYAscLQCpAPRhQbrORP6mt8+/N2I4FUlbh1RdRbNv913Y0i DezN3apBmlc7noogY6XF9G2KSaWthu10hjXCSWXdfhJWWypBLbdcPEjNhJwUSrTtjuC7 497Q==
X-Gm-Message-State: AEkoouvG3bac2R7JxjbP6nhZdoZ+4ZWomJYI6HxyKtrPOI/g4ZCgI0OvWM+DsmOQ8OhheA==
X-Received: by 10.194.116.1 with SMTP id js1mr3218844wjb.183.1471349393573; Tue, 16 Aug 2016 05:09:53 -0700 (PDT)
Received: from [10.36.226.98] ([80.169.137.53]) by smtp.googlemail.com with ESMTPSA id s184sm21468157wmb.11.2016.08.16.05.09.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Aug 2016 05:09:52 -0700 (PDT)
To: Brian Campbell 
References: <8472e581-1382-a364-a232-07ce6eeb0115@gmail.com> <852DC4F5-B9A0-4402-8550-6AB725546C63@ve7jtb.com> <9912591c-ce6c-b13c-e9f2-f0fb66b557d8@gmail.com> <6b6457e2-9cf1-9fdc-25f8-a0ee6be6976e@gmail.com> 
From: Sergey Beryozkin 
Message-ID: <154f9cd4-23e1-d0ac-e90a-badbe9e9d483@gmail.com>
Date: Tue, 16 Aug 2016 13:09:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] JWS JWT Access Tokens and resource audiences
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, 16 Aug 2016 12:17:34 -0000

Hi Brian

Thanks, 'cid' is a proper compact name :-), I've made our code 
configurable - to support reporting a client_id property either as a 
'client_id' or 'cid' claim.

Cheers, Sergey

On 12/08/16 23:30, Brian Campbell wrote:
> Yeah, the client typically isn't the/an audience of an access token. The
> AT is opaque to the client and the client never processes or validates
> it. So aud would have the resource(s) and something else could carry the
> client id.
>
> FWIW, token exchange is looking to define and register "cid" as a JWT
> claim for the client identifier:
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-05#section-4.3
>
> On Fri, Aug 12, 2016 at 4:13 AM, Sergey Beryozkin  > wrote:
>
>     Hi,
>
>
>     After updating my earlier code (where 'client_id' was set as the
>     standard JWT access token 'aud' property) to use 'aud' to represent
>     the resource audiences I'm now thinking how to represent a
>     'client_id' in this token.
>
>     For now if I'm using a 'client_id' claim, to be consistent with a
>     standard token introspection response.
>
>     The other thing is how to represent a name of the user who
>     authorized the code grant which was exchanged for this token.
>
>     Again I'm using a "username" claim, to be consistent with a standard
>     token introspection response.
>
>     Also thinking, what value if any a 'sub' claim in such a token
>     should have. I'm setting it to a unique user identifier (similarly
>     to IdToken).
>
>     Any comments are welcome
>
>     Sergey
>
>
>     On 11/08/16 23:30, Sergey Beryozkin wrote:
>
>         Hi John
>         On 11/08/16 23:24, John Bradley wrote:
>
>             I think most people put the a resource URI in the aud.
>
>             Connect uses the client ID as that is bit more stable than
>             trying to
>             use a redirect URI when there could be multiple ones.
>             Given that a resource server doesn’t typically have a
>             client_id the
>             resource uri make a reasonable value.
>
>             You could put it in resource if you like, but that is
>             probably not
>             what others are doing.
>
>         I was suspecting I might be on my own here yes :-)
>
>
>             It may be time for a interoperable JWT access token profile
>             of some sort.
>
>
>         +1
>
>             We keep getting close with some of the PoP stuff but only
>             specify parts.
>
>
>         Thanks, Sergey
>
>
>             John B.
>
>                 On Aug 11, 2016, at 6:16 PM, Sergey Beryozkin
>                 >
>                 wrote:
>
>                 Hi All
>
>                 Awhile back I was asking why would self-contained JWS
>                 JWT access
>                 tokens would be used (as opposed to JWE JWTs), my
>                 concern was that
>                 anyone with a JWT library can read this token's content
>                 - but as I
>                 was explained that should not be a problem if such a JWS
>                 JWT token
>                 contains non-sensitive information. Besides, in some
>                 cases, it gives
>                 RS an option to validate this JWS JWT locally, without
>                 having to make
>                 a remote validation call.
>
>                 So I've started experimenting and the immediate question
>                 I have is
>                 this one: which claim should one use to represent a
>                 resource server
>                 audience to get the most inter-operable RS level
>                 validation logic ?
>
>                 For example, a given RS may talk to different 3rd party
>                 authorization
>                 servers, say AS1 (vendor1) and AS2 (vendor2), and either
>                 AS1 or AS2
>                 JWS JWT tokens that this RS validates locally should
>                 ideally use the
>                 same claim to represent a resource audience. RS
>                 validation logic is
>                 written independently (without using AS1 or AS2 aware
>                 validation
>                 libraries).
>
>                 We do expect such requirements coming in our
>                 deployments. AS1 &
>                 independent validation logic is already in use. Just a
>                 matter of time
>                 before AS2 is introduced.
>
>                 So JWT has a standard 'aud' claim - but I believe this
>                 should be a
>                 'clientId' of the client a token is issued to, similarly
>                 to the way
>                 the 'aud' is treated in IdToken.
>
>                 So I've prototyped the code where JWT has these claims:
>
>                 "aud" = clientId
>                 "resource" = 'http://myResourceServer'
>
>                 where 'resource' is borrowed from OAuth2 Resource
>                 Indicators draft
>                 and represent a specific RS target address, the resource
>                 server
>                 audience.
>
>                 Am I on the right path ? How would others do it when
>                 facing a task of
>                 including a resource audience in a self-contained JWS
>                 JWT access token ?
>
>                 Many thanks, Sergey
>
>                 _______________________________________________
>                 OAuth mailing list
>                 OAuth@ietf.org 
>                 https://www.ietf.org/mailman/listinfo/oauth
>                 
>
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>     
>
>


From nobody Tue Aug 16 11:45:32 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2C312B041 for ; Tue, 16 Aug 2016 11:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiRM7XbpiWF4 for ; Tue, 16 Aug 2016 11:45:29 -0700 (PDT)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 4150412B00B for ; Tue, 16 Aug 2016 11:45:29 -0700 (PDT)
Received: by mail-io0-x229.google.com with SMTP id q83so115811751iod.1 for ; Tue, 16 Aug 2016 11:45:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tRrRWneaCyc0r0oX0XGGunvc0bQ7dRmpEaTAd9bxtSc=; b=VIECTsUad3XPh0ZBMVHM8n7Wc8+Ws4Woo6jri00louxYLrZJJZdSQiWqpPzPfNfBlK HSypOr3GD4vi/lqBs4t1qsXLTxV2UAYKD/E/DaB8+IS0Faf/FllVXa6KYRBXkb+FD/WZ 9bzgQ29qwH4EaMwBV5E6y7l+UmmpTG1xea/xU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tRrRWneaCyc0r0oX0XGGunvc0bQ7dRmpEaTAd9bxtSc=; b=hatIS/d73EwrJkJtfrHjCO7rM686l05hRS4eawtMC8LgwQHVL5R21LGD+vZfrqg/4R 5h3409yUdmVrloAkw6Bx2dOV4V16TaT9s2t+g3lImJ3jkZXTMyIiSgXIU0WXCgY+xpg9 2gzWgQCJamk4HW4H081094/QvZVTXYpJRsAKpu3i1VGxR/dkMy2mFgdhKn6xfNpTL3y5 fr2KJ0WbVUl1CVQ51v4vtLp0z/bmd/mgNWffjur18Pi4fhUQolV31X+VeVuu96VsEupG vVql+n5Y4ltenOONhnYvfFRxbIORjJ6qWa4uhzDp9lh93lDnz/8mP/6DIzj/LXYdtNvr 21YA==
X-Gm-Message-State: AEkoousrzjlgjAtGgWcLzoJa5/EyQUDNTJLiTGubmkGVbmiNAf7JLZ57DlmpQechoBwx71xrem4i6iYe56SkVV9B
X-Received: by 10.107.50.19 with SMTP id y19mr40700132ioy.174.1471373128545; Tue, 16 Aug 2016 11:45:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.123.14 with HTTP; Tue, 16 Aug 2016 11:44:58 -0700 (PDT)
In-Reply-To: <33052033-0992-ceb8-4390-6837017b140e@gmx.net>
References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net>
From: Brian Campbell 
Date: Tue, 16 Aug 2016 12:44:58 -0600
Message-ID: 
To: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=001a114469c4a8d5cd053a34c06b
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
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, 16 Aug 2016 18:45:31 -0000

--001a114469c4a8d5cd053a34c06b
Content-Type: text/plain; charset=UTF-8

Just a friendly reminder that the 'deadline' for this call for adoption is
tomorrow.

According to the minutes from Berlin
, 13 people
were in favor of adopting OAuth 2.0 Token Binding and 0 were against.

On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig  wrote:

> Hi all,
>
> this is the call for adoption of the 'OAuth 2.0 Token Binding' document
> bundle* following the positive call for adoption at the recent IETF
> meeting in Berlin.
>
> Here are the links to the documents presented at the last IETF meeting:
> https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
> https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
>
> Please let us know by August 17th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Derek
>
> *: We will find out what the best document structure is later, i.e.,
> whether the content should be included in one, two or multiple documents.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--001a114469c4a8d5cd053a34c06b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Just a friendly reminder that the 'deadline' for t=
his call for adoption is tomorrow. 

According to the minutes from=
 Berlin, 13 people were in favor of adopting OAuth 2.0 Token Binding an=
d 0 were against. 

On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,



this is the call for adoption of the 'OAuth 2.0 Token Binding' docu=
ment

bundle* following the positive call for adoption at the recent IETF

meeting in Berlin.



Here are the links to the documents presented at the last IETF meeting:

https://tools.ietf.org/html/draft=
-jones-oauth-token-binding-00

https://tools.ietf.org/html/draft-ca=
mpbell-oauth-tbpkce-00



Please let us know by August 17th whether you accept / object to the

adoption of this document as a starting point for work in the OAuth

working group.



Ciao

Hannes & Derek



*: We will find out what the best document structure is later, i.e.,

whether the content should be included in one, two or multiple documents.



_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth





--001a114469c4a8d5cd053a34c06b--


From nobody Tue Aug 16 14:26:43 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F8912D0F9 for ; Tue, 16 Aug 2016 14:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.032
X-Spam-Level: 
X-Spam-Status: No, score=-0.032 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, HTTPS_HTTP_MISMATCH=1.989, 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 L9W2zMiE_VaM for ; Tue, 16 Aug 2016 14:26:38 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0118.outbound.protection.outlook.com [104.47.41.118]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B0512D0BB for ; Tue, 16 Aug 2016 14:26:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ro+wmv9nKzSRNSxBt2Y4FI1vgkpseGWRrbQa7T6s1bw=; b=h9e4yfWSq0EbI+9+VXXBNnSy3hlXuIyHHMd9BD3YsWMiFR4d3hP25r4Zop0Vfx2Tm3v/jm/kGy6VJhCvxLWO1+jKfxgamZ4kHNaRkXgyIv9IYngg91zfhcm7P/ZCOYHXjKPwyIwviv0UAaVGJuVi4UqFxIl/0/F1ALqIVVR7tXE=
Received: from DM5PR03MB2441.namprd03.prod.outlook.com (10.168.233.11) by DM5PR03MB2442.namprd03.prod.outlook.com (10.168.233.12) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Tue, 16 Aug 2016 21:26:35 +0000
Received: from DM5PR03MB2441.namprd03.prod.outlook.com ([10.168.233.11]) by DM5PR03MB2441.namprd03.prod.outlook.com ([10.168.233.11]) with mapi id 15.01.0557.022; Tue, 16 Aug 2016 21:26:36 +0000
From: Anthony Nadalin 
To: Brian Campbell , Hannes Tschofenig 
Thread-Topic: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
Thread-Index: AQHR7VsVXBWWa50u8keGtWSWbPYGoaBMAd0AgAAsymA=
Date: Tue, 16 Aug 2016 21:26:35 +0000
Message-ID: 
References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net> 
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:b::2c4]
x-ms-office365-filtering-correlation-id: fa7a9120-138c-4b1b-c0e0-08d3c61c0095
x-microsoft-exchange-diagnostics: 1; DM5PR03MB2442; 6:OcUQcaWNHlWhriv70fUkQCFXvVRXpE7T+zVPLmqiq1Bv/IP8VM1qRpEyKBwK69/+E2yV2LmDneEu6Ptm3g38DWE8M3u+H9uME8DNUbQUS0NhOlQHcxSXU7HHWaNDgaI3kZnXCGVgsAbjBXP5KzGtaSsv1C3Jf4J02Y3l2dOlyzhyPcFNC4maAfwUBCRPTuf+6It9WbcKgazQ8jCmgSUn3DzWScnbUYg5yNewNnQkFbmZd41nB+hgAw8yTWRaRAWP1Wq7I+14PR6tCPOGnw8FfFxoxC8xh3aQL5YUgU7tYyhP3eME0rClwTTOfeYnGdloDlE1+fuO/OFJL+InUFRykg==; 5:zv2ThN9OzBiLkTIxMviYUZO0djLpQwTqqr567ezr4E7pchlXtA53brOWqwFNjLM3NzdPuAU8DKEuLXvnZnIcE6aWB2EjzVAaPPlpCMWLRzNNXfyYSHBGm3eOlRnAAJGkdFPiM6bpuuDUEzHqvjExiw==; 24:HtTvCOYn9JKoYx+VHh2LjgzBc+kTpBqwXYly8rGjhZenmpndRDybtKfsQkO7BPfZgJSsDzY2YKr/5tocUHejP27y6Sl0v3YPssH8KGrK4ro=; 7:9JyJx19gBABYLB30XaQOmjvq9IF96PTDDlSLD6HRevB7szK7e2/9UZIc5jpG+BwEVeS67VNIUrazY0OxbC4zA1Tk+CL0m7ISB0fKAx+9nNiZrVBXij9kxrN5yV/yGiMRdeukgBu0e0faiBsWoO8dbgkhSqMPSUsJK1+XzyPtDyQDC5k1otKyPiiJhws7SMWcAJoHenLIIAQe3ME4pCIWwp1FpA+Q1Ktz+YtS4X1Ixcj4q40gqUhOBrhxrEJ5p+JK
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR03MB2442;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(189930954265078)(248736688235697)(219752817060721)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM5PR03MB2442; BCL:0; PCL:0; RULEID:; SRVR:DM5PR03MB2442; 
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(53754006)(24454002)(189002)(377454003)(199003)(7906003)(4326007)(77096005)(2950100001)(2900100001)(3280700002)(54356999)(8676002)(86612001)(81156014)(33656002)(16236675004)(19580405001)(81166006)(106356001)(74316002)(19580395003)(9686002)(10400500002)(15975445007)(2906002)(10290500002)(86362001)(10090500001)(19617315012)(76576001)(7736002)(68736007)(5005710100001)(7696003)(7846002)(92566002)(19609705001)(8990500004)(76176999)(50986999)(19300405004)(105586002)(8936002)(99286002)(102836003)(189998001)(101416001)(19625215002)(790700001)(5002640100001)(106116001)(122556002)(586003)(6116002)(5001770100001)(3660700001)(97736004)(87936001)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR03MB2442; H:DM5PR03MB2441.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: multipart/alternative; boundary="_000_DM5PR03MB24410E438754ABA6FFE20C4CA6130DM5PR03MB2441namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2016 21:26:35.9399 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2442
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
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, 16 Aug 2016 21:26:41 -0000

--_000_DM5PR03MB24410E438754ABA6FFE20C4CA6130DM5PR03MB2441namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmW0gT0sgd2l0aCB0aGUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVz
LW9hdXRoLXRva2VuLWJpbmRpbmctMDA8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u
Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZk
cmFmdC1qb25lcy1vYXV0aC10b2tlbi1iaW5kaW5nLTAwJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQl
NDBtaWNyb3NvZnQuY29tJTdjYWFhODVmNDQ3OTUxNDU2YmY3M2MwOGQzYzYwNTgyYWElN2M3MmY5
ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9eHZTT0NYOUZGTGRKV2lrYnh6
eEtnakVXalUlMmZycVpzMW1tc3ZOc0ZIV1p3JTNkPiBidXQgbm90IHN1cmUgdGhhdCBodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtdGJwa2NlLTAwPGh0dHBz
Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJm
JTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtY2FtcGJlbGwtb2F1dGgtdGJwa2NlLTAw
JmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjYWFhODVmNDQ3OTUxNDU2
YmY3M2MwOGQzYzYwNTgyYWElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEm
c2RhdGE9Z0RRSUFvaGszdU5JTWdSbDVkTmdvZlFyODMySVdsYm91bWdmeWNuUG1ZZyUzZD4gaXMg
YSBnb29kIHN0YXJ0aW5nIHBvaW50IGFzIHdlIHdvdWxkIHdhbnQgYSBtb3JlIGdlbmVyaWMgc29s
dXRpb24gZm9yIFBvUCB0b2tlbnMgaW4gZ2VuZXJhbA0KDQoNCkZyb206IE9BdXRoIFttYWlsdG86
b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50
OiBUdWVzZGF5LCBBdWd1c3QgMTYsIDIwMTYgMTE6NDUgQU0NClRvOiBIYW5uZXMgVHNjaG9mZW5p
ZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4NCkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVj
dDogUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgYWRvcHRpb246IFRva2VuIEJpbmRpbmcgZm9yIE9B
dXRoIDIuMA0KDQpKdXN0IGEgZnJpZW5kbHkgcmVtaW5kZXIgdGhhdCB0aGUgJ2RlYWRsaW5lJyBm
b3IgdGhpcyBjYWxsIGZvciBhZG9wdGlvbiBpcyB0b21vcnJvdy4NCg0KQWNjb3JkaW5nIHRvIHRo
ZSBtaW51dGVzIGZyb20gQmVybGluPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v
dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmcHJvY2VlZGluZ3Ml
MmY5NiUyZm1pbnV0ZXMlMmZtaW51dGVzLTk2LW9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQl
NDBtaWNyb3NvZnQuY29tJTdjYWFhODVmNDQ3OTUxNDU2YmY3M2MwOGQzYzYwNTgyYWElN2M3MmY5
ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9NVVmQ2ROS3QyaVZ1RmZkaVNF
THFHdG85eUZTdXpqUnZkazlyQmxHeU16OCUzZD4sIDEzIHBlb3BsZSB3ZXJlIGluIGZhdm9yIG9m
IGFkb3B0aW5nIE9BdXRoIDIuMCBUb2tlbiBCaW5kaW5nIGFuZCAwIHdlcmUgYWdhaW5zdC4NCg0K
T24gV2VkLCBBdWcgMywgMjAxNiBhdCAxOjQ1IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVz
LnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdy
b3RlOg0KSGkgYWxsLA0KDQp0aGlzIGlzIHRoZSBjYWxsIGZvciBhZG9wdGlvbiBvZiB0aGUgJ09B
dXRoIDIuMCBUb2tlbiBCaW5kaW5nJyBkb2N1bWVudA0KYnVuZGxlKiBmb2xsb3dpbmcgdGhlIHBv
c2l0aXZlIGNhbGwgZm9yIGFkb3B0aW9uIGF0IHRoZSByZWNlbnQgSUVURg0KbWVldGluZyBpbiBC
ZXJsaW4uDQoNCkhlcmUgYXJlIHRoZSBsaW5rcyB0byB0aGUgZG9jdW1lbnRzIHByZXNlbnRlZCBh
dCB0aGUgbGFzdCBJRVRGIG1lZXRpbmc6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtam9uZXMtb2F1dGgtdG9rZW4tYmluZGluZy0wMDxodHRwczovL25hMDEuc2FmZWxpbmtzLnBy
b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJm
aHRtbCUyZmRyYWZ0LWpvbmVzLW9hdXRoLXRva2VuLWJpbmRpbmctMDAmZGF0YT0wMSU3YzAxJTdj
dG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NhYWE4NWY0NDc5NTE0NTZiZjczYzA4ZDNjNjA1ODJh
YSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT14dlNPQ1g5RkZM
ZEpXaWtieHp4S2dqRVdqVSUyZnJxWnMxbW1zdk5zRkhXWnclM2Q+DQpodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtY2FtcGJlbGwtb2F1dGgtdGJwa2NlLTAwPGh0dHBzOi8vbmEwMS5z
YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMu
aWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtY2FtcGJlbGwtb2F1dGgtdGJwa2NlLTAwJmRhdGE9MDEl
N2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjYWFhODVmNDQ3OTUxNDU2YmY3M2MwOGQz
YzYwNTgyYWElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9Z0RR
SUFvaGszdU5JTWdSbDVkTmdvZlFyODMySVdsYm91bWdmeWNuUG1ZZyUzZD4NCg0KUGxlYXNlIGxl
dCB1cyBrbm93IGJ5IEF1Z3VzdCAxN3RoIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0byB0
aGUNCmFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29y
ayBpbiB0aGUgT0F1dGgNCndvcmtpbmcgZ3JvdXAuDQoNCkNpYW8NCkhhbm5lcyAmIERlcmVrDQoN
Cio6IFdlIHdpbGwgZmluZCBvdXQgd2hhdCB0aGUgYmVzdCBkb2N1bWVudCBzdHJ1Y3R1cmUgaXMg
bGF0ZXIsIGkuZS4sDQp3aGV0aGVyIHRoZSBjb250ZW50IHNob3VsZCBiZSBpbmNsdWRlZCBpbiBv
bmUsIHR3byBvciBtdWx0aXBsZSBkb2N1bWVudHMuDQoNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0
Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v
ay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5m
byUyZm9hdXRoJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjYWFhODVm
NDQ3OTUxNDU2YmY3M2MwOGQzYzYwNTgyYWElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx
ZGI0NyU3YzEmc2RhdGE9RTlIVUk1SlVMJTJmWXclMmZ2bkVXR0J3RXUyOHIlMmZOZEY1M3Jkb0xQ
NSUyZlU0NnVVJTNkPg0KDQo=

--_000_DM5PR03MB24410E438754ABA6FFE20C4CA6130DM5PR03MB2441namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z
b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K
CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy
aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox
LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl
ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8
bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48
IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu
az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPknigJltIE9LIHdpdGggdGhlDQo8L3NwYW4+PGEgaHJlZj0i
aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl
M2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1qb25lcy1vYXV0aC10b2tlbi1i
aW5kaW5nLTAwJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2Fh
YTg1ZjQ0Nzk1MTQ1NmJmNzNjMDhkM2M2MDU4MmFhJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj
ZDAxMWRiNDclN2MxJmFtcDtzZGF0YT14dlNPQ1g5RkZMZEpXaWtieHp4S2dqRVdqVSUyZnJxWnMx
bW1zdk5zRkhXWnclM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtam9uZXMtb2F1dGgtdG9rZW4tYmluZGluZy0wMDwvYT4NCiBidXQgbm90IHN1cmUg
dGhhdCA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j
b20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWNhbXBi
ZWxsLW9hdXRoLXRicGtjZS0wMCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29m
dC5jb20lN2NhYWE4NWY0NDc5NTE0NTZiZjczYzA4ZDNjNjA1ODJhYSU3YzcyZjk4OGJmODZmMTQx
YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9Z0RRSUFvaGszdU5JTWdSbDVkTmdvZlFy
ODMySVdsYm91bWdmeWNuUG1ZZyUzZCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXBiZWxsLW9hdXRoLXRicGtjZS0wMDwvYT4gaXMgYSBnb29k
IHN0YXJ0aW5nIHBvaW50IGFzIHdlIHdvdWxkIHdhbnQgYSBtb3JlIGdlbmVyaWMgc29sdXRpb24g
Zm9yIFBvUCB0b2tlbnMgaW4gZ2VuZXJhbDxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxF
bmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48
L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0K
PGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz
ZGF5LCBBdWd1c3QgMTYsIDIwMTYgMTE6NDUgQU08YnI+DQo8Yj5Ubzo8L2I+IEhhbm5lcyBUc2No
b2ZlbmlnICZsdDtoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4g
b2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gQ2FsbCBm
b3IgYWRvcHRpb246IFRva2VuIEJpbmRpbmcgZm9yIE9BdXRoIDIuMDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3QgYSBmcmllbmRseSByZW1pbmRlciB0aGF0IHRoZSAn
ZGVhZGxpbmUnIGZvciB0aGlzIGNhbGwgZm9yIGFkb3B0aW9uIGlzIHRvbW9ycm93Lg0KPG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQWNjb3JkaW5nIHRv
IHRoZSA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j
b20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZnByb2NlZWRpbmdzJTJmOTYlMmZt
aW51dGVzJTJmbWludXRlcy05Ni1vYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1p
Y3Jvc29mdC5jb20lN2NhYWE4NWY0NDc5NTE0NTZiZjczYzA4ZDNjNjA1ODJhYSU3YzcyZjk4OGJm
ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9NVVmQ2ROS3QyaVZ1RmZkaVNF
THFHdG85eUZTdXpqUnZkazlyQmxHeU16OCUzZCI+DQptaW51dGVzIGZyb20gQmVybGluPC9hPiwg
MTMgcGVvcGxlIHdlcmUgaW4gZmF2b3Igb2YgYWRvcHRpbmcgT0F1dGggMi4wIFRva2VuIEJpbmRp
bmcgYW5kIDAgd2VyZSBhZ2FpbnN0Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDMsIDIwMTYgYXQgMTo0NSBBTSwgSGFu
bmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgu
bmV0IiB0YXJnZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn
aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgYWxsLDxicj4NCjxicj4NCnRoaXMgaXMgdGhl
IGNhbGwgZm9yIGFkb3B0aW9uIG9mIHRoZSAnT0F1dGggMi4wIFRva2VuIEJpbmRpbmcnIGRvY3Vt
ZW50PGJyPg0KYnVuZGxlKiBmb2xsb3dpbmcgdGhlIHBvc2l0aXZlIGNhbGwgZm9yIGFkb3B0aW9u
IGF0IHRoZSByZWNlbnQgSUVURjxicj4NCm1lZXRpbmcgaW4gQmVybGluLjxicj4NCjxicj4NCkhl
cmUgYXJlIHRoZSBsaW5rcyB0byB0aGUgZG9jdW1lbnRzIHByZXNlbnRlZCBhdCB0aGUgbGFzdCBJ
RVRGIG1lZXRpbmc6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0
aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwl
MmZkcmFmdC1qb25lcy1vYXV0aC10b2tlbi1iaW5kaW5nLTAwJmFtcDtkYXRhPTAxJTdjMDElN2N0
b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2FhYTg1ZjQ0Nzk1MTQ1NmJmNzNjMDhkM2M2MDU4MmFh
JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT14dlNPQ1g5
RkZMZEpXaWtieHp4S2dqRVdqVSUyZnJxWnMxbW1zdk5zRkhXWnclM2QiIHRhcmdldD0iX2JsYW5r
Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtdG9rZW4tYmlu
ZGluZy0wMDwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp
b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUy
ZmRyYWZ0LWNhbXBiZWxsLW9hdXRoLXRicGtjZS0wMCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5h
ZCU0MG1pY3Jvc29mdC5jb20lN2NhYWE4NWY0NDc5NTE0NTZiZjczYzA4ZDNjNjA1ODJhYSU3Yzcy
Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9Z0RRSUFvaGszdU5J
TWdSbDVkTmdvZlFyODMySVdsYm91bWdmeWNuUG1ZZyUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1wYmVsbC1vYXV0aC10YnBrY2UtMDA8L2E+
PGJyPg0KPGJyPg0KUGxlYXNlIGxldCB1cyBrbm93IGJ5IEF1Z3VzdCAxN3RoIHdoZXRoZXIgeW91
IGFjY2VwdCAvIG9iamVjdCB0byB0aGU8YnI+DQphZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGFz
IGEgc3RhcnRpbmcgcG9pbnQgZm9yIHdvcmsgaW4gdGhlIE9BdXRoPGJyPg0Kd29ya2luZyBncm91
cC48YnI+DQo8YnI+DQpDaWFvPGJyPg0KSGFubmVzICZhbXA7IERlcmVrPGJyPg0KPGJyPg0KKjog
V2Ugd2lsbCBmaW5kIG91dCB3aGF0IHRoZSBiZXN0IGRvY3VtZW50IHN0cnVjdHVyZSBpcyBsYXRl
ciwgaS5lLiw8YnI+DQp3aGV0aGVyIHRoZSBjb250ZW50IHNob3VsZCBiZSBpbmNsdWRlZCBpbiBv
bmUsIHR3byBvciBtdWx0aXBsZSBkb2N1bWVudHMuPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3Jn
PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs
b29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3Rp
bmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdj
YWFhODVmNDQ3OTUxNDU2YmY3M2MwOGQzYzYwNTgyYWElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk
N2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPUU5SFVJNUpVTCUyZll3JTJmdm5FV0dCd0V1MjhyJTJm
TmRGNTNyZG9MUDUlMmZVNDZ1VSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_DM5PR03MB24410E438754ABA6FFE20C4CA6130DM5PR03MB2441namp_--


From nobody Wed Aug 17 00:40:15 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BF112D11A for ; Wed, 17 Aug 2016 00:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.947
X-Spam-Level: 
X-Spam-Status: No, score=-3.947 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=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjP95icFEJ9F for ; Wed, 17 Aug 2016 00:40:12 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0A812B058 for ; Wed, 17 Aug 2016 00:40:11 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id i5so214663498wmg.0 for ; Wed, 17 Aug 2016 00:40:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XHth0uA7MtJmb4bNu7ewmKnYJ9ljTZif4R6I93KgBhM=; b=TASACjGL+dhPFbG5AEYuBFmVGr/x9nLlpGqKFvQdcblsRuiyQ4KQDR3OnfJQN9Gd+p nHZlwRjVpP6HoOXw/2DSyIiz0qgvgI+nzsFeFolOPpR6a6FTP/X1H4YyeBC4MwT+wRLx 1wqtQTjCS3U3XDe3MXi0FYedMv4653NYgzDHAUwDjlZ42x6DlWItj6pEqGsmq3nfakYg VeG32GUEgEQp2+A9eQWbYOBw6hH832Es4iggIwKpsVqihj1Dwq+bkCQ/ZG1XhfHAXuPN lH1zNFr0YAh9ksyFn4UeVYAKNLOT+7MVFCVrE1i11EekSNSABqS1NClwT49StQNlEg6q IFAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XHth0uA7MtJmb4bNu7ewmKnYJ9ljTZif4R6I93KgBhM=; b=Wu6mE9KF9/3Czh1+9uuEvCh1AFCkkBvlRQMPkAutgSIxOIqDtUYsiXwqlGzVp4eORg Ml+0NYdeWrmzN1Bg1ZLhRbUbxSz6/RJestBab+fhjQipAFgNawCe/lfHKah1nzFf0B/j 9evBMUmyS2w4dz2mqQXxkZG2mYwRlviuuNEHryKU1vMC7Wb87nIvRtQJ9jI6uhWWk0+v f1BRl1RgVVrGT6/PCjd2TUiOAAp6txchA1MLmZeCE6R4+9tfE5IeDA0is+K+KLAovjMk oaoctzUqzEvfxjvTljXqH3fLUn2nhLUFkIuIdO/AvE6RL/fRyQUx5kFmNCltXPKclNlp H+yw==
X-Gm-Message-State: AEkoouvj0PN6NL2+um/2nlxeB1P9jIKX5ujcJgjRRIj1mlPizklLognyxsHprTJ5IJ8s3kcawP07y6++qq4WYTRS
X-Received: by 10.194.238.170 with SMTP id vl10mr43238162wjc.18.1471419610042;  Wed, 17 Aug 2016 00:40:10 -0700 (PDT)
MIME-Version: 1.0
References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net> 
In-Reply-To: 
From: Dirk Balfanz 
Date: Wed, 17 Aug 2016 07:39:58 +0000
Message-ID: 
To: John Bradley , Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=089e014934ac2c9fbd053a3f93b1
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
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, 17 Aug 2016 07:40:13 -0000

--089e014934ac2c9fbd053a3f93b1
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 3, 2016 at 1:48 PM John Bradley  wrote:

> I accept these documents as a starting point of the Token binding work in
> OAuth.
>

Same here. I accept adoption as a starting point.

Dirk.


>
> John B.
> > On Aug 3, 2016, at 3:45 AM, Hannes Tschofenig 
> wrote:
> >
> > Hi all,
> >
> > this is the call for adoption of the 'OAuth 2.0 Token Binding' document
> > bundle* following the positive call for adoption at the recent IETF
> > meeting in Berlin.
> >
> > Here are the links to the documents presented at the last IETF meeting:
> > https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
> > https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
> >
> > Please let us know by August 17th whether you accept / object to the
> > adoption of this document as a starting point for work in the OAuth
> > working group.
> >
> > Ciao
> > Hannes & Derek
> >
> > *: We will find out what the best document structure is later, i.e.,
> > whether the content should be included in one, two or multiple documents.
> >
> > _______________________________________________
> > 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
>

--089e014934ac2c9fbd053a3f93b1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed=
, Aug 3, 2016 at 1:48 PM John Bradley <ve7jtb@ve7jtb.com> wrote:



John B.

> On Aug 3, 2016, at 3:45 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
; wrote:

>

> Hi all,

>

> this is the call for adoption of the 'OAuth 2.0 Token Binding'=
 document

> bundle* following the positive call for adoption at the recent IETF
> meeting in Berlin.

>

> Here are the links to the documents presented at the last IETF meeting=
:

> https://tools.ietf.org/html/draft=
-jones-oauth-token-binding-00

> https://tools.ietf.org/html/draft-cam=
pbell-oauth-tbpkce-00

>

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

>

> Ciao

> Hannes & Derek

>

> *: We will find out what the best document structure is later, i.e.,
> whether the content should be included in one, two or multiple documen=
ts.

>

> _______________________________________________

> 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




--089e014934ac2c9fbd053a3f93b1--


From nobody Wed Aug 17 01:38:15 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602AF12D187 for ; Wed, 17 Aug 2016 01:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDU9PuH6ww_L for ; Wed, 17 Aug 2016 01:38:10 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) (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 964E612D0D8 for ; Wed, 17 Aug 2016 01:38:10 -0700 (PDT)
Received: from [80.140.198.142] (helo=[10.8.0.6]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.84) (envelope-from ) id 1bZwMR-0000ei-KJ; Wed, 17 Aug 2016 10:38:07 +0200
Message-ID: <57B4226D.5060205@lodderstedt.net>
Date: Wed, 17 Aug 2016 10:38:05 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Dirk Balfanz , John Bradley ,  Hannes Tschofenig 
References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net>  
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060907030700060201020704"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
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, 17 Aug 2016 08:38:13 -0000

This is a multi-part message in MIME format.
--------------060907030700060201020704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

+1

Am 17.08.2016 09:39, schrieb Dirk Balfanz:
>
>
> On Wed, Aug 3, 2016 at 1:48 PM John Bradley  > wrote:
>
>     I accept these documents as a starting point of the Token binding
>     work in OAuth.
>
>
> Same here. I accept adoption as a starting point.
>
> Dirk.
>
>
>     John B.
>     > On Aug 3, 2016, at 3:45 AM, Hannes Tschofenig
>     > wrote:
>     >
>     > Hi all,
>     >
>     > this is the call for adoption of the 'OAuth 2.0 Token Binding'
>     document
>     > bundle* following the positive call for adoption at the recent IETF
>     > meeting in Berlin.
>     >
>     > Here are the links to the documents presented at the last IETF
>     meeting:
>     > https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
>     > https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
>     >
>     > Please let us know by August 17th whether you accept / object to the
>     > adoption of this document as a starting point for work in the OAuth
>     > working group.
>     >
>     > Ciao
>     > Hannes & Derek
>     >
>     > *: We will find out what the best document structure is later, i.e.,
>     > whether the content should be included in one, two or multiple
>     documents.
>     >
>     > _______________________________________________
>     > 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


--------------060907030700060201020704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1

    

    
Am 17.08.2016 09:39, schrieb Dirk
      Balfanz:

    

    

      


        

        

          
On Wed, Aug 3, 2016 at 1:48 PM John Bradley
            <ve7jtb@ve7jtb.com>
            wrote:

          

          
I accept
            these documents as a starting point of the Token binding
            work in OAuth.

          

          


          

          
Same here. I accept adoption as a starting point.

          


          

          
Dirk.

          
 

          

            

            John B.

            > On Aug 3, 2016, at 3:45 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>
            wrote:

            >

            > Hi all,

            >

            > this is the call for adoption of the 'OAuth 2.0 Token
            Binding' document

            > bundle* following the positive call for adoption at the
            recent IETF

            > meeting in Berlin.

            >

            > Here are the links to the documents presented at the
            last IETF meeting:

            > https://tools.ietf.org/html/draft-jones-oauth-token-binding-00

            > https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00

            >

            > Please let us know by August 17th whether you accept /
            object to the

            > adoption of this document as a starting point for work
            in the OAuth

            > working group.

            >

            > Ciao

            > Hannes & Derek

            >

            > *: We will find out what the best document structure is
            later, i.e.,

            > whether the content should be included in one, two or
            multiple documents.

            >

            > _______________________________________________

            > 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


    

    

  


--------------060907030700060201020704--


From nobody Wed Aug 17 06:40:14 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C0B12D739 for ; Wed, 17 Aug 2016 06:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEiKqfs0-dlu for ; Wed, 17 Aug 2016 06:40:10 -0700 (PDT)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) (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 0858912D917 for ; Wed, 17 Aug 2016 06:40:09 -0700 (PDT)
Received: from [37.58.176.163] (helo=[172.16.2.26]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.84) (envelope-from ) id 1ba14h-0000x4-80; Wed, 17 Aug 2016 15:40:07 +0200
Message-ID: <57B46936.90704@lodderstedt.net>
Date: Wed, 17 Aug 2016 15:40:06 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: John Bradley ,  Vladimir Dzhuvinov 
References:  <52f75ab0-9072-49dd-635b-da5de4014312@connect2id.com> <3B1ED07C-6BF9-44DA-BC05-ACD5AFF63868@ve7jtb.com>
In-Reply-To: <3B1ED07C-6BF9-44DA-BC05-ACD5AFF63868@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------030800000304040704070303"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Metadata Specifications Enhanced
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, 17 Aug 2016 13:40:13 -0000

This is a multi-part message in MIME format.
--------------030800000304040704070303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

It does not adress the relationship between resource and scope.

Am 04.08.2016 22:12, schrieb John Bradley:
> This was proposed 
> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
>
> It seemed to be a bit too controversial for the WG to accept at the 
> time it was discussed.
>
> John B.
>> On Aug 4, 2016, at 6:33 AM, Vladimir Dzhuvinov 
>> > wrote:
>>
>> Thanks Mike for the updates.
>>
>> These two specs (along with token exchange and perhaps others) 
>> effectively codify "resource" as a key OAuth 2.0 property and 
>> parameter, alongside "scope". RFC 6749 however only specifies "scope" 
>> in authz and token requests.
>>
>> Have there been any thoughts how to reconcile this?
>>
>> Vladimir
>>
>>
>> On 03/08/16 23:57, Mike Jones wrote:
>>> The existing OAuth 2.0 Authorization Server Metadata  specification has now been joined by a related OAuth 2.0 Protected Resource Metadata  specification.  This means that JSON metadata formats are now defined for all the OAuth 2.0 parties: clients, authorization servers, and protected resources.
>>>
>>> The most significant addition to the OAuth 2.0 Authorization Server Metadata specification is enabling signed metadata, represented as claims in a JSON Web Token (JWT).  This is analogous to the role that the Software Statement plays in OAuth Dynamic Client Registration.  Signed metadata can also be used for protected resource metadata.
>>>
>>> For use cases in which the set of protected resources used with an authorization server are enumerable, the authorization server metadata specification now defines the "protected_resources" metadata value to list them.  Likewise, the protected resource metadata specification defines an "authorization_servers" metadata value to list the authorization servers that can be used with a protected resource, for use cases in which those are enumerable.
>>>
>>> The specifications are available at:
>>>
>>> *http://tools.ietf.org/html/draft-ietf-oauth-discovery-04
>>>
>>> *http://tools.ietf.org/html/draft-jones-oauth-resource-metadata-00
>>>
>>> HTML-formatted versions are also available at:
>>>
>>> *http://self-issued.info/docs/draft-ietf-oauth-discovery-04.html
>>>
>>> *http://self-issued.info/docs/draft-jones-oauth-resource-metadata-00.html
>>>
>>>                                                         -- Mike
>>>
>>> P.S.  This notice was also posted athttp://self-issued.info/?p=1591  and as @selfissued.
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> -- 
>> Vladimir Dzhuvinov
>> _______________________________________________
>> 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


--------------030800000304040704070303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    It does not adress the relationship between resource and scope.

    

    
Am 04.08.2016 22:12, schrieb John
      Bradley:

    

    

      
      This was proposed https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
      


      

      
It seemed to be a bit too controversial for the WG
        to accept at the time it was discussed.

      


      

      
John B.

        

          

            

              
On Aug 4, 2016, at 6:33 AM, Vladimir
                Dzhuvinov <vladimir@connect2id.com>
                wrote:

              

              

                
                

                  
Thanks Mike for the updates.

                  
These two specs (along with token exchange
                    and perhaps others) effectively codify "resource" as
                    a key OAuth 2.0 property and parameter, alongside
                    "scope". RFC 6749 however only specifies "scope" in
                    authz and token requests.

                  
Have there been any thoughts how to
                    reconcile this?

                  
Vladimir

                  

                  


                  

                  
On 03/08/16 23:57, Mike
                    Jones wrote:

                  

                  

                    
The existing OAuth 2.0 Authorization Server Metadata<https://tools.ietf.org/html/draft-ietf-oauth-discovery> specification has now been joined by a related OAuth 2.0 Protected Resource Metadata<https://tools.ietf.org/html/draft-jones-oauth-resource-metadata> specification.  This means that JSON metadata formats are now defined for all the OAuth 2.0 parties: clients, authorization servers, and protected resources.

The most significant addition to the OAuth 2.0 Authorization Server Metadata specification is enabling signed metadata, represented as claims in a JSON Web Token (JWT).  This is analogous to the role that the Software Statement plays in OAuth Dynamic Client Registration.  Signed metadata can also be used for protected resource metadata.

For use cases in which the set of protected resources used with an authorization server are enumerable, the authorization server metadata specification now defines the "protected_resources" metadata value to list them.  Likewise, the protected resource metadata specification defines an "authorization_servers" metadata value to list the authorization servers that can be used with a protected resource, for use cases in which those are enumerable.

The specifications are available at:

*       http://tools.ietf.org/html/draft-ietf-oauth-discovery-04

*       http://tools.ietf.org/html/draft-jones-oauth-resource-metadata-00

HTML-formatted versions are also available at:

*       http://self-issued.info/docs/draft-ietf-oauth-discovery-04.html

*       http://self-issued.info/docs/draft-jones-oauth-resource-metadata-00.html

                                                       -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=1591 and as @selfissued<https://twitter.com/selfissued>.



                    

                    

                    

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


                  

                  

                  
-- 
Vladimir Dzhuvinov

                

                _______________________________________________

                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


    

    

  


--------------030800000304040704070303--


From nobody Wed Aug 17 09:07:52 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD0B12DA6A for ; Wed, 17 Aug 2016 09:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Hb2-8R0JolxY for ; Wed, 17 Aug 2016 09:07:48 -0700 (PDT)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 DA85E12D739 for ; Wed, 17 Aug 2016 09:07:47 -0700 (PDT)
Received: by mail-ua0-x229.google.com with SMTP id k90so178797509uak.1 for ; Wed, 17 Aug 2016 09:07:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3oB7V4soNl6wucKXPWuIcwm8fucwqa+ZRLEXEmi5xog=; b=PWHgJHk+HvIVVCklDkBx+n9FY4wnZr4X6DPsetpXU0uQAISKp1vPlHndc6RsyQ4f5I 7rUtIchfIr4FmRMi/4qLwoB0mq93bzAmxc9oUrJTvEQeq3qrJAFGoLjew8u2NDlN8i/c GFu+9qGaouWW98nGk2KYvce/fE1WArOZV6zQjz6+EJgKLIG0BS1bM2EQ0BXfuCg2XQq8 x9jIDhYLen64k5LTG5wIpeGuFYpwmUreG5msj3cHWhZNZHX6NSSmeiQ6mx0+mqKEQQZ/ 1tSlIdIFkT8AUaN78zN5yzFbJoMgt3XvuXOfMSZAxHkhLcH28YzfSp2MsrREok/ALjgL rMBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3oB7V4soNl6wucKXPWuIcwm8fucwqa+ZRLEXEmi5xog=; b=C2GgGEDoNbtYrzaFVhSU01zvjEQLHRE/jycWYzVNkW7bLwq0d1mqykzMlLS3Cprdkf Q6kWN97dfaVxwpxCV/Cfbt/C1uuuMVERnagOJZo57GRdwQOIUuo9kUxJder5TYciahCn 6nBtkaCQk/2Fbd3flNLWXkuInIIKGLFHMvXHE1qI1uU6PsrlpetPB+/ARUMESAY5Wjd0 Alzr2k+Pr6gG96NSpq8r1A/gDciSsKaQwf6x25QvT33C6MUrxcFcbI1qA/WoPOkOMvQz lPZxaGEAB4cczJU5a5z+PbU/77lBlcE27rjrV4vFJV33LvdjSjdNaJRLmriPNaoTRkXV gHrg==
X-Gm-Message-State: AEkoouu/ocin9eMXE9gyTOnx4bwczN7w2KCMkKI1w+HIvNO+t3kisPeWw+aJ4TcpA8c50lBKAGPZ/nRyQhc/cw==
X-Received: by 10.159.36.209 with SMTP id 75mr20081823uar.138.1471450066881; Wed, 17 Aug 2016 09:07:46 -0700 (PDT)
MIME-Version: 1.0
References:  <52f75ab0-9072-49dd-635b-da5de4014312@connect2id.com> <3B1ED07C-6BF9-44DA-BC05-ACD5AFF63868@ve7jtb.com>
In-Reply-To: <3B1ED07C-6BF9-44DA-BC05-ACD5AFF63868@ve7jtb.com>
From: Nat Sakimura 
Date: Wed, 17 Aug 2016 16:07:35 +0000
Message-ID: 
To: John Bradley , Vladimir Dzhuvinov 
Content-Type: multipart/alternative; boundary=001a113d00208a952b053a46aaab
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Metadata Specifications Enhanced
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, 17 Aug 2016 16:07:50 -0000

--001a113d00208a952b053a46aaab
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>From a security protocols design point of view, it is a good practice to
indicate what entity in what role are going to be involved in what
sequence. So, including a resource indicator in the authorization request
is good - if it does not stop there and it is possible at all.
Resource indicator needs to support the notion of the group identifier and
allowed processing on them (combined, it sometimes is called `scope`) as
well.

Then, there is a problem of authorization request / response not tamper
protected nor source authenticated. To be really useful, it also has to be
addressed.

Nat

2016=E5=B9=B48=E6=9C=885=E6=97=A5(=E9=87=91) 5:13 John Bradley :

> This was proposed
> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01
>
> It seemed to be a bit too controversial for the WG to accept at the time
> it was discussed.
>
> John B.
>
> On Aug 4, 2016, at 6:33 AM, Vladimir Dzhuvinov 
> wrote:
>
> Thanks Mike for the updates.
>
> These two specs (along with token exchange and perhaps others) effectivel=
y
> codify "resource" as a key OAuth 2.0 property and parameter, alongside
> "scope". RFC 6749 however only specifies "scope" in authz and token
> requests.
>
> Have there been any thoughts how to reconcile this?
>
> Vladimir
>
>
> On 03/08/16 23:57, Mike Jones wrote:
>
> The existing OAuth 2.0 Authorization Server Metadata  specification has now been joined by a related OAuth 2.0 =
Protected Resource Metadata  specification.  This means that JSON metadata formats are now defi=
ned for all the OAuth 2.0 parties: clients, authorization servers, and prot=
ected resources.
>
> The most significant addition to the OAuth 2.0 Authorization Server Metad=
ata specification is enabling signed metadata, represented as claims in a J=
SON Web Token (JWT).  This is analogous to the role that the Software State=
ment plays in OAuth Dynamic Client Registration.  Signed metadata can also =
be used for protected resource metadata.
>
> For use cases in which the set of protected resources used with an author=
ization server are enumerable, the authorization server metadata specificat=
ion now defines the "protected_resources" metadata value to list them.  Lik=
ewise, the protected resource metadata specification defines an "authorizat=
ion_servers" metadata value to list the authorization servers that can be u=
sed with a protected resource, for use cases in which those are enumerable.
>
> The specifications are available at:
>
> *       http://tools.ietf.org/html/draft-ietf-oauth-discovery-04
>
> *       http://tools.ietf.org/html/draft-jones-oauth-resource-metadata-00
>
> HTML-formatted versions are also available at:
>
> *       http://self-issued.info/docs/draft-ietf-oauth-discovery-04.html
>
> *       http://self-issued.info/docs/draft-jones-oauth-resource-metadata-=
00.html
>
>                                                        -- Mike
>
> P.S.  This notice was also posted at http://self-issued.info/?p=3D1591 an=
d as @selfissued .
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
> --
> Vladimir Dzhuvinov
>
> _______________________________________________
> 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

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a113d00208a952b053a46aaab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


From a security protocols design point of v=
iew, it is a good practice to indicate what entity in what role are going t=
o be involved in what sequence. So, including a resource indicator in the a=
uthorization request is good - if it does not stop there and it is possible=
 at all. 

Resource indicator needs to support the notion of the group identifier and =
allowed processing on them (combined, it sometimes is called `scope`) as we=
ll.=C2=A0


Then, there is a problem of authorization request / response=
 not tamper protected nor source authenticated. To be really useful, it als=
o has to be addressed. 
Nat


2016=E5=B9=B48=E6=9C=885=E6=
=97=A5(=E9=87=91) 5:13 John Bradley <ve7jtb@ve7jtb.com>:
This was proposed=C2=A0https://tools.ietf.=
org/html/draft-campbell-oauth-resource-indicators-01

It seemed to be a bit too controversial for the WG to accept at the time i=
t was discussed.

John B.

On =
Aug 4, 2016, at 6:33 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:

 =20
   =20
 =20
  
Thanks Mike for the updates.=

These two specs (along with token exchange and perhaps others)
      effectively codify "resource" as a key OAuth 2.0 property a=
nd
      parameter, alongside "scope". RFC 6749 however only specifi=
es
      "scope" in authz and token requests.
Have there been =
any thoughts how to reconcile this?
Vladimir

    


    

    
On 03/08/16 23:57, Mike Jones wrote:

    

    

      
The existing OAuth 2.0 Authorization Server Metadata&l=
t;https://tools.ietf.org/html/draft-ietf-oauth-discovery> specificat=
ion has now been joined by a related OAuth 2.0 Protected Resource Metadata<=
a href=3D"https://tools.ietf.org/html/draft-jones-oauth-resource-metadata" =
target=3D"_blank"><https://tools.ietf.org/html/draft-jones-oauth-resourc=
e-metadata> specification.  This means that JSON metadata formats ar=
e now defined for all the OAuth 2.0 parties: clients, authorization servers=
, and protected resources.

The most significant addition to the OAuth 2.0 Authorization Server Metadat=
a specification is enabling signed metadata, represented as claims in a JSO=
N Web Token (JWT).  This is analogous to the role that the Software Stateme=
nt plays in OAuth Dynamic Client Registration.  Signed metadata can also be=
 used for protected resource metadata.

For use cases in which the set of protected resources used with an authoriz=
ation server are enumerable, the authorization server metadata specificatio=
n now defines the "protected_resources" metadata value to list th=
em.  Likewise, the protected resource metadata specification defines an &qu=
ot;authorization_servers" metadata value to list the authorization ser=
vers that can be used with a protected resource, for use cases in which tho=
se are enumerable.

The specifications are available at:

*       http://tools.ietf.org/html/draft-ietf-oauth-discovery-0=
4

*       http://tools.ietf.org/html/draft-jones-oauth-r=
esource-metadata-00

HTML-formatted versions are also available at:

*       http://self-issued.info/docs/draft-ietf-oauth-di=
scovery-04.html

*       http://self-issued.info/docs/draft-jone=
s-oauth-resource-metadata-00.html

                                                       -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=3D1591 and as @se=
lfissued<ht=
tps://twitter.com/selfissued>.



      

      

      

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


    

    

    
--=20
Vladimir Dzhuvinov

  


_______________________________________________
OAuth mailing list
OAuth@ietf.org
http=
s://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




--001a113d00208a952b053a46aaab--


From nobody Wed Aug 17 09:25:03 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0394812B074 for ; Wed, 17 Aug 2016 09:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.467
X-Spam-Level: 
X-Spam-Status: No, score=-5.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, 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 YE5GRw3T4lpN for ; Wed, 17 Aug 2016 09:24:57 -0700 (PDT)
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 9C2E612DACD for ; Wed, 17 Aug 2016 09:24:55 -0700 (PDT)
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 u7HGOoLV020864 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Aug 2016 16:24:51 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id u7HGOo4v028449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 17 Aug 2016 16:24:50 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7HGOnTi021136; Wed, 17 Aug 2016 16:24:49 GMT
Received: from [10.0.1.5] (/24.86.208.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 17 Aug 2016 09:24:49 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_4149B96A-300A-4A30-9429-6646B5840874"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Phil Hunt 
In-Reply-To: 
Date: Wed, 17 Aug 2016 09:24:47 -0700
Message-Id: <72DD1B83-8062-4D17-8CF2-3BA531D454FD@oracle.com>
References:  <52f75ab0-9072-49dd-635b-da5de4014312@connect2id.com> <3B1ED07C-6BF9-44DA-BC05-ACD5AFF63868@ve7jtb.com> 
To: Nat Sakimura 
X-Mailer: Apple Mail (2.3124)
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Metadata Specifications Enhanced
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, 17 Aug 2016 16:24:59 -0000

--Apple-Mail=_4149B96A-300A-4A30-9429-6646B5840874
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1.  This is more in line with the alternate proposal submitted =
previously - and probably expressed better. :)
  https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00


Phil

@independentid
www.independentid.com =
phil.hunt@oracle.com =






> On Aug 17, 2016, at 9:07 AM, Nat Sakimura  wrote:
>=20
> =46rom a security protocols design point of view, it is a good =
practice to indicate what entity in what role are going to be involved =
in what sequence. So, including a resource indicator in the =
authorization request is good - if it does not stop there and it is =
possible at all.=20
> Resource indicator needs to support the notion of the group identifier =
and allowed processing on them (combined, it sometimes is called =
`scope`) as well.=20
>=20
> Then, there is a problem of authorization request / response not =
tamper protected nor source authenticated. To be really useful, it also =
has to be addressed.
>=20
> Nat
>=20
>=20
> 2016=E5=B9=B48=E6=9C=885=E6=97=A5(=E9=87=91) 5:13 John Bradley =
>:
> This was proposed =
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01 =

>=20
> It seemed to be a bit too controversial for the WG to accept at the =
time it was discussed.
>=20
> John B.
>=20
>> On Aug 4, 2016, at 6:33 AM, Vladimir Dzhuvinov =
> wrote:
>>=20
>> Thanks Mike for the updates.
>>=20
>> These two specs (along with token exchange and perhaps others) =
effectively codify "resource" as a key OAuth 2.0 property and parameter, =
alongside "scope". RFC 6749 however only specifies "scope" in authz and =
token requests.
>>=20
>> Have there been any thoughts how to reconcile this?
>>=20
>> Vladimir
>>=20
>> On 03/08/16 23:57, Mike Jones wrote:
>>> The existing OAuth 2.0 Authorization Server =
Metadata =
 specification =
has now been joined by a related OAuth 2.0 Protected Resource =
Metadata =
 =
specification.  This means that JSON metadata formats are now defined =
for all the OAuth 2.0 parties: clients, authorization servers, and =
protected resources.
>>>=20
>>> The most significant addition to the OAuth 2.0 Authorization Server =
Metadata specification is enabling signed metadata, represented as =
claims in a JSON Web Token (JWT).  This is analogous to the role that =
the Software Statement plays in OAuth Dynamic Client Registration.  =
Signed metadata can also be used for protected resource metadata.
>>>=20
>>> For use cases in which the set of protected resources used with an =
authorization server are enumerable, the authorization server metadata =
specification now defines the "protected_resources" metadata value to =
list them.  Likewise, the protected resource metadata specification =
defines an "authorization_servers" metadata value to list the =
authorization servers that can be used with a protected resource, for =
use cases in which those are enumerable.
>>>=20
>>> The specifications are available at:
>>>=20
>>> *       http://tools.ietf.org/html/draft-ietf-oauth-discovery-04 =

>>>=20
>>> *       =
http://tools.ietf.org/html/draft-jones-oauth-resource-metadata-00 =

>>>=20
>>> HTML-formatted versions are also available at:
>>>=20
>>> *       =
http://self-issued.info/docs/draft-ietf-oauth-discovery-04.html =

>>>=20
>>> *       =
http://self-issued.info/docs/draft-jones-oauth-resource-metadata-00.html =
=

>>>=20
>>>                                                        -- Mike
>>>=20
>>> P.S.  This notice was also posted at http://self-issued.info/?p=3D1591=
  and as =
@selfissued =
.
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

>>=20
>> --=20
>> Vladimir Dzhuvinov
>> _______________________________________________
>> 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
> Nat Sakimura
>=20
> Chairman of the Board, OpenID Foundation
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_4149B96A-300A-4A30-9429-6646B5840874
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1.  This is more in line with the alternate proposal =
submitted previously - and probably expressed better. :)
  https://tools.ietf.org/html/draft-hunt-oauth-bound-config-00









On Aug 17, 2016, at 9:07 AM, Nat Sakimura <sakimura@gmail.com> =
wrote:

=46rom a security =
protocols design point of view, it is a good practice to indicate what =
entity in what role are going to be involved in what sequence. So, =
including a resource indicator in the authorization request is good - if =
it does not stop there and it is possible at all. 

Resource indicator needs to support the notion of the group identifier =
and allowed processing on them (combined, it sometimes is called =
`scope`) as well. 
Then, there is a =
problem of authorization request / response not tamper protected nor =
source authenticated. To be really useful, it also has to be addressed. =

Nat


2016=E5=B9=B48=E6=9C=885=E6=97=A5(=E9=87=91) 5:13 John =
Bradley <ve7jtb@ve7jtb.com>:
This was proposed https://tools.ietf.org/html/draft-campbell-oauth-resource-indic=
ators-01

It =
seemed to be a bit too controversial for the WG to accept at the time it =
was discussed.

John B.

On Aug =
4, 2016, at 6:33 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:


 =20
   =20
 =20
  
Thanks Mike for the updates.
These two specs =
(along with token exchange and perhaps others)
      effectively codify "resource" as a key OAuth 2.0 property and
      parameter, alongside "scope". RFC 6749 however only specifies
      "scope" in authz and token requests.
Have there =
been any thoughts how to reconcile this?
Vladimir

    


    

    
On 03/08/16 23:57, Mike Jones wrote:

    

    

      
The existing OAuth 2.0 Authorization Server =
Metadata<https://tools.ietf.org/html/draft-ietf-oauth-discovery><=
/a> specification has now been joined by a related OAuth 2.0 Protected =
Resource Metadata<https://tools.ietf.org/html/draft-jones-oauth-resource-meta=
data> specification.  This means that JSON metadata formats are =
now defined for all the OAuth 2.0 parties: clients, authorization =
servers, and protected resources.

The most significant addition to the OAuth 2.0 Authorization Server =
Metadata specification is enabling signed metadata, represented as =
claims in a JSON Web Token (JWT).  This is analogous to the role that =
the Software Statement plays in OAuth Dynamic Client Registration.  =
Signed metadata can also be used for protected resource metadata.

For use cases in which the set of protected resources used with an =
authorization server are enumerable, the authorization server metadata =
specification now defines the "protected_resources" metadata value to =
list them.  Likewise, the protected resource metadata specification =
defines an "authorization_servers" metadata value to list the =
authorization servers that can be used with a protected resource, for =
use cases in which those are enumerable.

The specifications are available at:

*       http://tools.ietf.org/html/draft-ietf-oauth-discovery-04

*       http://tools.ietf.org/html/draft-jones-oauth-resource-metadata-=
00

HTML-formatted versions are also available at:

*       http://self-issued.info/docs/draft-ietf-oauth-discovery-04.html=


*       http://self-issued.info/docs/draft-jones-oauth-resource-metadat=
a-00.html

                                                       -- Mike

P.S.  This notice was also posted at http://self-issued.info/?p=3D1591 and as @selfissued<https://twitter.com/selfissued>.



      

      

      

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


    

    

    
--=20
Vladimir Dzhuvinov

  


_______________________________________________
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



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

=

--Apple-Mail=_4149B96A-300A-4A30-9429-6646B5840874--


From nobody Wed Aug 17 18:45:10 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588A612D831; Wed, 17 Aug 2016 18:45:09 -0700 (PDT)
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, 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 rGfZAB6Akfqu; Wed, 17 Aug 2016 18:45:07 -0700 (PDT)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8185612D504; Wed, 17 Aug 2016 18:45:06 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.28,536,1464616800";  d="scan'208,217";a="188423905"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 18 Aug 2016 11:45:01 +1000
X-IronPort-AV: E=McAfee;i="5700,7163,8260"; a="206519773"
Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbvi.tcif.telstra.com.au with ESMTP; 18 Aug 2016 11:45:01 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3707.srv.dir.telstra.com ([fe80::ccc:aa8f:d2a6:740%28]) with mapi; Thu, 18 Aug 2016 11:45:01 +1000
From: "Manger, James" 
To: "oauth-ext-review@ietf.org" 
Date: Thu, 18 Aug 2016 11:45:00 +1000
Thread-Topic: Request for error code: all those from OAuth 2.0 core [RFC6749]
Thread-Index: AdH48fjP88QF+ZP/Qy6hFHVgjb79UQ==
Message-ID: <255B9BB34FB7D647A506DC292726F6E13BFED73FC6@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BFED73FC6WSMSG3153Vsrv_"
MIME-Version: 1.0
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: [OAUTH-WG] Request for error code: all those from OAuth 2.0 core [RFC6749]
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, 18 Aug 2016 01:45:09 -0000

--_000_255B9BB34FB7D647A506DC292726F6E13BFED73FC6WSMSG3153Vsrv_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The IANA "OAuth Extensions Error Registry" doesn't list most=
 of the errors defined in the core OAuth 2.0 spec [RFC6749], only those add=
ed by other specs.

This is just annoying. It would be far more useful for the IANA registry to=
 be a single source of all OAuth 2.0 error codes.

I suggest listing the following to the registry (with RFC6749 as the refere=
nce, and perhaps "core" as the "extension"):

access_denied
invalid_client
invalid_grant
invalid_scope
server_error
temporarily_unavailable
unauthorized_client
unsupported_grant_type
unsupported_response_type

--
James Manger


--_000_255B9BB34FB7D647A506DC292726F6E13BFED73FC6WSMSG3153Vsrv_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The IANA=
 “OAuth Extensions Error Registry”=
; doesn’t list most of the errors defined in the core OAuth 2.0 spec =
[RFC6749], only those added by other specs.
 
This is just annoying. It wou=
ld be far more useful for the IANA registry to be a single source of all OA=
uth 2.0 error codes.
 
I suggest listing the following to the registry (wit=
h RFC6749 as the reference, and perhaps “core” as the “ex=
tension”):
 
access_denied
invalid=
_client
invalid_grant
invalid_scope
server_er=
ror
temporarily_unavailable
unauthorized_client
unsupported_grant_type
unsupported_re=
sponse_type
 
--
James=
 Manger
 
=

--_000_255B9BB34FB7D647A506DC292726F6E13BFED73FC6WSMSG3153Vsrv_--


From nobody Fri Aug 19 14:54:03 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC9C12D597 for ; Fri, 19 Aug 2016 14:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.06
X-Spam-Level: 
X-Spam-Status: No, score=-2.06 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, FREEMAIL_REPLYTO=1, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, REPTO_QUOTE_YAHOO=0.646, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n4oY4Fxm-gA for ; Fri, 19 Aug 2016 14:54:00 -0700 (PDT)
Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) (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 2854A127058 for ; Fri, 19 Aug 2016 14:54:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1471643639; bh=3JsJy5nfMRRwuxPRlA8vVub2A6U1C0bOPY1y1XXsruM=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=rW9/fSSjlf7dsTrA3Q2qzUgFjo0uL+14tS77fesHi1XMmnZ4atB5t5hNcz07XMgO0/smcr1+kPTE60I6HpmgHv+VTd8CxLo9cyfZ6Yrg9s7fjow5gh6gA22V5UGkXpGQ7ucKReAd0Oex3hXyox24iKwHkokJlpdFlT7X7vTyrkT0/idka5lIdlfq1H3fU70d6EivnnWOnB8WNLsU9x6TE7AKi94H2HhejZvDOhdNerjHWB5mYPFlNxDCxodXsoAQ5Wf8saM4VSqmJ9Xc5glacVbba6OAAtIs29w7dQyVCaO+tdW0JVw2M4XGowmEyqCDz1Zn3B+raIVi+WFMUmfi4A==
Received: from [66.196.81.171] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 19 Aug 2016 21:53:59 -0000
Received: from [98.139.212.233] by tm17.bullet.mail.bf1.yahoo.com with NNFMP;  19 Aug 2016 21:53:59 -0000
Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 19 Aug 2016 21:53:59 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 136373.24609.bm@omp1042.mail.bf1.yahoo.com
Received: from jws106190.mail.bf1.yahoo.com by sendmailws141.mail.bf1.yahoo.com; Fri, 19 Aug 2016 21:53:58 +0000; 1471643638.685
Date: Fri, 19 Aug 2016 21:53:57 +0000 (UTC)
From: Sheena Carrillo 
To: "oauth@ietf.org" ,  "oauth-request@ietf.org" ,  "oauth@ietf.org" 
Message-ID: <534635778.7879593.1471643637616.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_7879592_1382940071.1471643637612"
Archived-At: 
Subject: [OAUTH-WG] =?utf-8?b?MTE6MTA3LiBzcGFjZcK/IGJyaWRnZUDCpF86O18p?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "sheenasman86@yahoo.com" 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 21:54:02 -0000

------=_Part_7879592_1382940071.1471643637612
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Sent from Yahoo Mail on Android=20
=20
  On Thu, Aug 18, 2016 at 12:00 PM, oauth-request@ietf.org wrote:   Send OAuth mailing list submissions to
=C2=A0=C2=A0=C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0=C2=A0=C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0=C2=A0=C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 1. Request for error code: all those from OAuth 2.0 core
=C2=A0 =C2=A0 =C2=A0 [RFC6749] (Manger, James)


----------------------------------------------------------------------

Message: 1
Date: Thu, 18 Aug 2016 11:45:00 +1000
From: "Manger, James" 
To: "oauth-ext-review@ietf.org" 
Cc: "oauth@ietf.org" 
Subject: [OAUTH-WG] Request for error code: all those from OAuth 2.0
=C2=A0=C2=A0=C2=A0 core=C2=A0=C2=A0=C2=A0 [RFC6749]
Message-ID:
=C2=A0=C2=A0=C2=A0 <255B9BB34FB7D647A506DC292726F6E13BFED73FC6@WSMSG3153V.s=
rv.dir.telstra.com>
=C2=A0=C2=A0=C2=A0=20
Content-Type: text/plain; charset=3D"us-ascii"

The IANA "OAuth Extensions Error Registry" doesn't list most=
 of the errors defined in the core OAuth 2.0 spec [RFC6749], only those add=
ed by other specs.

This is just annoying. It would be far more useful for the IANA registry to=
 be a single source of all OAuth 2.0 error codes.

I suggest listing the following to the registry (with RFC6749 as the refere=
nce, and perhaps "core" as the "extension"):

access_denied
invalid_client
invalid_grant
invalid_scope
server_error
temporarily_unavailable
unauthorized_client
unsupported_grant_type
unsupported_response_type

--
James Manger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

------------------------------

Subject: Digest Footer

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


------------------------------

End of OAuth Digest, Vol 94, Issue 25
*************************************
 =20

------=_Part_7879592_1382940071.1471643637612
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Sent from Yahoo Mail on Android 
 
 
 
On Thu, Aug 18, 2016 at 12:0=
0 PM, oauth-request@ietf.org
<oauth-request@ietf.org> wrote=
:
 
 
 
Send OAuth mailing list submissions to
&nbs=
p;   oauth@ietf.org

To subscribe or unsubscribe via the World Wid=
e Web, visit
    https://www.ietf.org/mailman/listinfo/oau=
th
or, via email, send a message with subject or body 'help' to
&=
nbsp;   oauth-request@ietf.org

You can reach the person m=
anaging the list at
    oauth-owner@ietf.org

When r=
eplying, please edit your Subject line so it is more specific
than "Re: =
Contents of OAuth digest..."


Today's Topics:

   1. R=
equest for error code: all those from OAuth 2.0 core
     =
; [RFC6749] (Manger, James)


------------------------------------=
----------------------------------

Message: 1
Date: Thu, 18 Aug 2=
016 11:45:00 +1000
From: "Manger, James" <James.H.Manger@team.t=
elstra.com>
To: "oauth-ext-review@ietf.org" <oauth-ext-rev=
iew@ietf.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: [OAUTH-WG=
] Request for error code: all those from OAuth 2.0
    co=
re    [RFC6749]
Message-ID:
    <255B9BB34FB7D647A506DC292726F6=
E13BFED73FC6@WSMSG3153V.srv.dir.telstra.com>
    <=
br>Content-Type: text/plain; charset=3D"us-ascii"

The IANA "OAuth Ex=
tensions Error Registry<http=
://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensi=
ons-error>" doesn't list most of the errors defined in the core OAut=
h 2.0 spec [RFC6749], only those added by other specs.

This is just =
annoying. It would be far more useful for the IANA registry to be a single =
source of all OAuth 2.0 error codes.

I suggest listing the following=
 to the registry (with RFC6749 as the reference, and perhaps "core" as the =
"extension"):

access_denied
invalid_client
invalid_grant
in=
valid_scope
server_error
temporarily_unavailable
unauthorized_clie=
nt
unsupported_grant_type
unsupported_response_type

--
Jame=
s Manger

-------------- next part --------------
An HTML attachme=
nt was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20160818/90c=
240b4/attachment.html>

------------------------------

=
Subject: Digest Footer

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


------------------------------

End of OAuth Di=
gest, Vol 94, Issue 25
*************************************
 <=
/div> 

------=_Part_7879592_1382940071.1471643637612--


From nobody Fri Aug 19 14:54:11 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B15012D5A2 for ; Fri, 19 Aug 2016 14:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.06
X-Spam-Level: 
X-Spam-Status: No, score=-2.06 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, FREEMAIL_REPLYTO=1, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, REPTO_QUOTE_YAHOO=0.646, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 141SGAOg-h3p for ; Fri, 19 Aug 2016 14:54:02 -0700 (PDT)
Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) (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 C66B912B076 for ; Fri, 19 Aug 2016 14:54:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1471643639; bh=3JsJy5nfMRRwuxPRlA8vVub2A6U1C0bOPY1y1XXsruM=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=rW9/fSSjlf7dsTrA3Q2qzUgFjo0uL+14tS77fesHi1XMmnZ4atB5t5hNcz07XMgO0/smcr1+kPTE60I6HpmgHv+VTd8CxLo9cyfZ6Yrg9s7fjow5gh6gA22V5UGkXpGQ7ucKReAd0Oex3hXyox24iKwHkokJlpdFlT7X7vTyrkT0/idka5lIdlfq1H3fU70d6EivnnWOnB8WNLsU9x6TE7AKi94H2HhejZvDOhdNerjHWB5mYPFlNxDCxodXsoAQ5Wf8saM4VSqmJ9Xc5glacVbba6OAAtIs29w7dQyVCaO+tdW0JVw2M4XGowmEyqCDz1Zn3B+raIVi+WFMUmfi4A==
Received: from [66.196.81.171] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 19 Aug 2016 21:53:59 -0000
Received: from [98.139.212.233] by tm17.bullet.mail.bf1.yahoo.com with NNFMP;  19 Aug 2016 21:53:59 -0000
Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 19 Aug 2016 21:53:59 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 136373.24609.bm@omp1042.mail.bf1.yahoo.com
Received: from jws106190.mail.bf1.yahoo.com by sendmailws141.mail.bf1.yahoo.com; Fri, 19 Aug 2016 21:53:58 +0000; 1471643638.685
Date: Fri, 19 Aug 2016 21:53:57 +0000 (UTC)
From: Sheena Carrillo 
To: "oauth@ietf.org" ,  "oauth-request@ietf.org" ,  "oauth@ietf.org" 
Message-ID: <534635778.7879593.1471643637616.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_7879592_1382940071.1471643637612"
Archived-At: 
Subject: [OAUTH-WG] =?utf-8?b?MTE6MTA3LiBzcGFjZcK/IGJyaWRnZUDCpF86O18p?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "sheenasman86@yahoo.com" 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 Aug 2016 21:54:04 -0000

------=_Part_7879592_1382940071.1471643637612
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Sent from Yahoo Mail on Android=20
=20
  On Thu, Aug 18, 2016 at 12:00 PM, oauth-request@ietf.org wrote:   Send OAuth mailing list submissions to
=C2=A0=C2=A0=C2=A0 oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
=C2=A0=C2=A0=C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0=C2=A0=C2=A0 oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

=C2=A0 1. Request for error code: all those from OAuth 2.0 core
=C2=A0 =C2=A0 =C2=A0 [RFC6749] (Manger, James)


----------------------------------------------------------------------

Message: 1
Date: Thu, 18 Aug 2016 11:45:00 +1000
From: "Manger, James" 
To: "oauth-ext-review@ietf.org" 
Cc: "oauth@ietf.org" 
Subject: [OAUTH-WG] Request for error code: all those from OAuth 2.0
=C2=A0=C2=A0=C2=A0 core=C2=A0=C2=A0=C2=A0 [RFC6749]
Message-ID:
=C2=A0=C2=A0=C2=A0 <255B9BB34FB7D647A506DC292726F6E13BFED73FC6@WSMSG3153V.s=
rv.dir.telstra.com>
=C2=A0=C2=A0=C2=A0=20
Content-Type: text/plain; charset=3D"us-ascii"

The IANA "OAuth Extensions Error Registry" doesn't list most=
 of the errors defined in the core OAuth 2.0 spec [RFC6749], only those add=
ed by other specs.

This is just annoying. It would be far more useful for the IANA registry to=
 be a single source of all OAuth 2.0 error codes.

I suggest listing the following to the registry (with RFC6749 as the refere=
nce, and perhaps "core" as the "extension"):

access_denied
invalid_client
invalid_grant
invalid_scope
server_error
temporarily_unavailable
unauthorized_client
unsupported_grant_type
unsupported_response_type

--
James Manger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

------------------------------

Subject: Digest Footer

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


------------------------------

End of OAuth Digest, Vol 94, Issue 25
*************************************
 =20

------=_Part_7879592_1382940071.1471643637612
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Sent from Yahoo Mail on Android 
 
 
 
On Thu, Aug 18, 2016 at 12:0=
0 PM, oauth-request@ietf.org
<oauth-request@ietf.org> wrote=
:
 
 
 
Send OAuth mailing list submissions to
&nbs=
p;   oauth@ietf.org

To subscribe or unsubscribe via the World Wid=
e Web, visit
    https://www.ietf.org/mailman/listinfo/oau=
th
or, via email, send a message with subject or body 'help' to
&=
nbsp;   oauth-request@ietf.org

You can reach the person m=
anaging the list at
    oauth-owner@ietf.org

When r=
eplying, please edit your Subject line so it is more specific
than "Re: =
Contents of OAuth digest..."


Today's Topics:

   1. R=
equest for error code: all those from OAuth 2.0 core
     =
; [RFC6749] (Manger, James)


------------------------------------=
----------------------------------

Message: 1
Date: Thu, 18 Aug 2=
016 11:45:00 +1000
From: "Manger, James" <James.H.Manger@team.t=
elstra.com>
To: "oauth-ext-review@ietf.org" <oauth-ext-rev=
iew@ietf.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: [OAUTH-WG=
] Request for error code: all those from OAuth 2.0
    co=
re    [RFC6749]
Message-ID:
    <255B9BB34FB7D647A506DC292726F6=
E13BFED73FC6@WSMSG3153V.srv.dir.telstra.com>
    <=
br>Content-Type: text/plain; charset=3D"us-ascii"

The IANA "OAuth Ex=
tensions Error Registry<http=
://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensi=
ons-error>" doesn't list most of the errors defined in the core OAut=
h 2.0 spec [RFC6749], only those added by other specs.

This is just =
annoying. It would be far more useful for the IANA registry to be a single =
source of all OAuth 2.0 error codes.

I suggest listing the following=
 to the registry (with RFC6749 as the reference, and perhaps "core" as the =
"extension"):

access_denied
invalid_client
invalid_grant
in=
valid_scope
server_error
temporarily_unavailable
unauthorized_clie=
nt
unsupported_grant_type
unsupported_response_type

--
Jame=
s Manger

-------------- next part --------------
An HTML attachme=
nt was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20160818/90c=
240b4/attachment.html>

------------------------------

=
Subject: Digest Footer

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


------------------------------

End of OAuth Di=
gest, Vol 94, Issue 25
*************************************
 <=
/div> 

------=_Part_7879592_1382940071.1471643637612--


From nobody Mon Aug 22 14:02:35 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2627E12D58A for ; Mon, 22 Aug 2016 14:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level: 
X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, 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 MJxNzjCQF9Su for ; Mon, 22 Aug 2016 14:02:31 -0700 (PDT)
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 9FA4712D80F for ; Mon, 22 Aug 2016 14:02:31 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id x131so110660610ite.0 for ; Mon, 22 Aug 2016 14:02:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZSbJtb/pRMQrgVKYNQFCYzeG2xMQmHOsigrIs0NnanU=; b=IPCBjtqf9Px4c3GhM5lzmNFfdigzmj0HnO7Yjvmc0+3ffoF/qIGnedFVY9icobf2BT L601jwiY4wvfvpRwe+LMandjhLhSkeZameNspWN98rWuZrxAs473rNNWFmkRZhlMLWwj XNPeT7QRX2D2NQPeRhQZF/WJM/WbP9iqUaL+s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZSbJtb/pRMQrgVKYNQFCYzeG2xMQmHOsigrIs0NnanU=; b=aYG//GDV6TuPLIFTKj6RdVFKag0Dio4kTWQHpXJvXXBeY4+ouLp0PlGeGzybKAEzMr c1WkDsIQt70r3Zx3MuCp6LAX+iOVKRVymezhQU4ni1m8rYmLoGEGIKphIY1h1n4I0z5j I64bgZUTaTPfuDT5kZHiM6MXZBXCuxmW7hwFkkm2NXn1Dwg8Uh6Y50teF8pSeYeyV5CC 2maU/WY5K4kSRd/niCqkSRwOxakvxiBs5n/uYluQIOfrY2inU+uIceofUS/qdALLgc50 vwq7DaUAEo4MXkObP9LVxv/7Q6mn0IIhHvMdD10S8c6bQ0T2v+UEMm2/HGNSvrZ7K87q x6KA==
X-Gm-Message-State: AEkooutFdB73nYYCrl97MHtiBuBSAHvT4rYp1bLk8vBA7k46wz2GNCMP7eO0THcytR8e3wF2RHMf5pbY/S+h8bpJ
X-Received: by 10.107.50.19 with SMTP id y19mr24882006ioy.174.1471899750948; Mon, 22 Aug 2016 14:02:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.123.14 with HTTP; Mon, 22 Aug 2016 14:02:00 -0700 (PDT)
In-Reply-To: 
References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net>  
From: Brian Campbell 
Date: Mon, 22 Aug 2016 15:02:00 -0600
Message-ID: 
To: Anthony Nadalin 
Content-Type: multipart/alternative; boundary=001a114469c4ccfde3053aaf5db3
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
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, 22 Aug 2016 21:02:34 -0000

--001a114469c4ccfde3053aaf5db3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree with Tony, if I understand what he's saying.
https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00

was largely a straw-man to get the conversation started. But after talking
with people in Berlin, reviewing Dirk's document, and thinking about it
some more - it's not clear that PKCE is a great fit for token binding the
authorization code.

Token binding the authorization code is, I think, something we want to
account for.  But using/extending PKCE might not be the way to go about it.
And whatever approach we land on should probably be just one part of the
larger document on OAuth 2.0 Token Binding.

On Tue, Aug 16, 2016 at 3:26 PM, Anthony Nadalin 
wrote:

> I=E2=80=99m OK with the https://tools.ietf.org/html/draft-jones-oauth-tok=
en-
> binding-00
> 
> but not sure that https://tools.ietf.org/html/
> draft-campbell-oauth-tbpkce-00
> 
> is a good starting point as we would want a more generic solution for PoP
> tokens in general
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian
> Campbell
> *Sent:* Tuesday, August 16, 2016 11:45 AM
> *To:* Hannes Tschofenig 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
>
>
>
> Just a friendly reminder that the 'deadline' for this call for adoption i=
s
> tomorrow.
>
>
> According to the minutes from Berlin
> ,
> 13 people were in favor of adopting OAuth 2.0 Token Binding and 0 were
> against.
>
>
>
> On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig <
> hannes.tschofenig@gmx.net> wrote:
>
> Hi all,
>
> this is the call for adoption of the 'OAuth 2.0 Token Binding' document
> bundle* following the positive call for adoption at the recent IETF
> meeting in Berlin.
>
> Here are the links to the documents presented at the last IETF meeting:
> https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
> 
> https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
> 
>
> Please let us know by August 17th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Derek
>
> *: We will find out what the best document structure is later, i.e.,
> whether the content should be included in one, two or multiple documents.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>
>
>

--001a114469c4ccfde3053aaf5db3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I agree with Tony, if I understand what he's saying. <=
a href=3D"https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%=
2ftools.ietf.org%2fhtml%2fdraft-campbell-oauth-tbpkce-00&data=3D01%7c01=
%7ctonynad%40microsoft.com%7caaa85f447951456bf73c08d3c60582aa%7c72f988bf86f=
141af91ab2d7cd011db47%7c1&sdata=3DgDQIAohk3uNIMgRl5dNgofQr832IWlboumgfy=
cnPmYg%3d" target=3D"_blank">https://tools.ietf.org/html/draft-campbel=
l-oauth-tbpkce-00 was largely a straw-man to get the conversation start=
ed. But after talking with people in Berlin, reviewing Dirk's document,=
 and thinking about it some more - it's not clear that PKCE is a great =
fit for token binding the authorization code. 

Token binding the aut=
horization code is, I think, something we want to account for.=C2=A0 But us=
ing/extending PKCE might not be the way to go about it. And whatever approa=
ch we land on should probably be just one part of the larger document on OA=
uth 2.0 Token Binding. 

On Tue, Aug 16, 2016 at 3:26 PM, Anthony Nadalin <ton=
ynad@microsoft.com> wrote:











I=E2=80=99m OK with the
https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
 but not sure that 
https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 is a go=
od starting point as we would want a more generic solution for PoP tokens i=
n general






<=
u>=C2=A0



From: OAuth [mailto:oauth-bounces@ietf.org=
]
On Behalf Of Brian Campbell

Sent: Tuesday, August 16, 2016 11:45 AM

To: Hannes Tschofenig <hannes.tschofenig@gmx.net>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for =
OAuth 2.0


=C2=A0




Just a friendly reminder that the 'deadline'=
 for this call for adoption is tomorrow.







According to the 
minutes from Berlin, 13 people were in favor of adopting OAuth 2.0 Toke=
n Binding and 0 were against.









=C2=A0




On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig &l=
t;hannes.tsc=
hofenig@gmx.net> wrote:




Hi all,



this is the call for adoption of the 'OAuth 2.0 Token Binding' docu=
ment

bundle* following the positive call for adoption at the recent IETF

meeting in Berlin.



Here are the links to the documents presented at the last IETF meeting:

https://tools.ietf.org/html/draft-=
jones-oauth-token-binding-00

https://tools.ietf.org/html/draft-campbe=
ll-oauth-tbpkce-00



Please let us know by August 17th whether you accept / object to the

adoption of this document as a starting point for work in the OAuth

working group.



Ciao

Hannes & Derek



*: We will find out what the best document structure is later, i.e.,

whether the content should be included in one, two or multiple documents.




_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth






=C2=A0












--001a114469c4ccfde3053aaf5db3--


From nobody Tue Aug 23 07:58:11 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC4B12DB36 for ; Tue, 23 Aug 2016 07:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.612
X-Spam-Level: 
X-Spam-Status: No, score=-0.612 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, 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 4JV1yI4Zt_9l for ; Tue, 23 Aug 2016 07:58:05 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.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 5F28212D9C8 for ; Tue, 23 Aug 2016 07:36:07 -0700 (PDT)
Received: from [37.58.176.162] (helo=[172.16.2.26]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1bcCo8-0006vT-EW; Tue, 23 Aug 2016 16:36:04 +0200
To: Brian Campbell , Anthony Nadalin 
References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net>   
From: Torsten Lodderstedt 
Message-ID: <57BC5F52.5040704@lodderstedt.net>
Date: Tue, 23 Aug 2016 16:36:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040207080001000008020706"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
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, 23 Aug 2016 14:58:09 -0000

This is a multi-part message in MIME format.
--------------040207080001000008020706
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

+1

I would also propose to focus use of token binding to detect replay of 
tokens (access, refresh, code)

Am 22.08.2016 um 23:02 schrieb Brian Campbell:
> I agree with Tony, if I understand what he's saying. 
> https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 
>  
> was largely a straw-man to get the conversation started. But after 
> talking with people in Berlin, reviewing Dirk's document, and thinking 
> about it some more - it's not clear that PKCE is a great fit for token 
> binding the authorization code.
>
> Token binding the authorization code is, I think, something we want to 
> account for.  But using/extending PKCE might not be the way to go 
> about it. And whatever approach we land on should probably be just one 
> part of the larger document on OAuth 2.0 Token Binding.
>
> On Tue, Aug 16, 2016 at 3:26 PM, Anthony Nadalin 
> > wrote:
>
>     I’m OK with the
>     https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
>     
>     but not sure that
>     https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
>     
>     is a good starting point as we would want a more generic solution
>     for PoP tokens in general
>
>     *From:*OAuth [mailto:oauth-bounces@ietf.org
>     ] *On Behalf Of *Brian Campbell
>     *Sent:* Tuesday, August 16, 2016 11:45 AM
>     *To:* Hannes Tschofenig      >
>     *Cc:* oauth@ietf.org 
>     *Subject:* Re: [OAUTH-WG] Call for adoption: Token Binding for
>     OAuth 2.0
>
>     Just a friendly reminder that the 'deadline' for this call for
>     adoption is tomorrow.
>
>
>     According to the minutes from Berlin
>     ,
>     13 people were in favor of adopting OAuth 2.0 Token Binding and 0
>     were against.
>
>     On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig
>     > wrote:
>
>         Hi all,
>
>         this is the call for adoption of the 'OAuth 2.0 Token Binding'
>         document
>         bundle* following the positive call for adoption at the recent
>         IETF
>         meeting in Berlin.
>
>         Here are the links to the documents presented at the last IETF
>         meeting:
>         https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
>         
>         https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
>         
>
>         Please let us know by August 17th whether you accept / object
>         to the
>         adoption of this document as a starting point for work in the
>         OAuth
>         working group.
>
>         Ciao
>         Hannes & Derek
>
>         *: We will find out what the best document structure is later,
>         i.e.,
>         whether the content should be included in one, two or multiple
>         documents.
>
>
>         _______________________________________________
>         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


--------------040207080001000008020706
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    +1 

    

    I would also propose to focus use of token binding to detect replay
    of tokens (access, refresh, code)

    

    
Am 22.08.2016 um 23:02 schrieb Brian
      Campbell:

    

    

      
I agree with Tony, if I understand what he's
        saying. https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
        was largely a straw-man to get the conversation started. But
        after talking with people in Berlin, reviewing Dirk's document,
        and thinking about it some more - it's not clear that PKCE is a
        great fit for token binding the authorization code. 

        

        Token binding the authorization code is, I think, something we
        want to account for.  But using/extending PKCE might not be the
        way to go about it. And whatever approach we land on should
        probably be just one part of the larger document on OAuth 2.0
        Token Binding. 

      

      


        
On Tue, Aug 16, 2016 at 3:26 PM,
          Anthony Nadalin <tonynad@microsoft.com>
          wrote:

          

            

              

                
I’m
                    OK with the
                  https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
                  but not sure that 
                    https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
                  is a good starting point as we would want a more
                  generic solution for PoP tokens in general

                  

                  

                
 

                
                
From:
                    OAuth [mailto:oauth-bounces@ietf.org]
                    On Behalf Of Brian Campbell

                    Sent: Tuesday, August 16, 2016 11:45 AM

                      To: Hannes Tschofenig <hannes.tschofenig@gmx.net>

                      Cc: oauth@ietf.org

                    Subject: Re: [OAUTH-WG] Call for
                    adoption: Token Binding for OAuth 2.0

                

                  

                    
 

                    

                      
Just a friendly reminder that
                        the 'deadline' for this call for adoption is
                        tomorrow.
                      

                      

                        


                          According to the 
                            minutes from Berlin, 13 people were in
                          favor of adopting OAuth 2.0 Token Binding and
                          0 were against.
                        

                      

                    

                    

                      
 

                      

                        
On Wed, Aug 3, 2016 at 1:45
                          AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>
                          wrote:

                        

                          
Hi all,

                            

                            this is the call for adoption of the 'OAuth
                            2.0 Token Binding' document

                            bundle* following the positive call for
                            adoption at the recent IETF

                            meeting in Berlin.

                            

                            Here are the links to the documents
                            presented at the last IETF meeting:

                            https://tools.ietf.org/html/draft-jones-oauth-token-binding-00

                            https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00

                            

                            Please let us know by August 17th whether
                            you accept / object to the

                            adoption of this document as a starting
                            point for work in the OAuth

                            working group.

                            

                            Ciao

                            Hannes & Derek

                            

                            *: We will find out what the best document
                            structure is later, i.e.,

                            whether the content should be included in
                            one, two or multiple documents.

                            

                            

                            _______________________________________________

                            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


    

    

  


--------------040207080001000008020706--


From phdrycke@gmail.com  Mon Aug 22 00:25:02 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC65712B036 for ; Mon, 22 Aug 2016 00:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 7H4yrXeYuqci for ; Mon, 22 Aug 2016 00:25:01 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8927E12B010 for ; Mon, 22 Aug 2016 00:24:58 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id u134so46584555ywg.3 for ; Mon, 22 Aug 2016 00:24:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=Hku9hzULfu2vnc0Wh7cMqLOPbVEx5+yFwXP5JwjGcxA=; b=gaBvXr4REuiOPCyj3+YzGd7GUup405S4C8snLU4eBfyFd4yfXvcMuOEQmGCz2GmAKN 944V7DXH1zsWlq8++93xOyczLKws5bCGJOUbcZQxc2J5OBr64JrC/Uu74F6B9VrkB2b4 P3FXXD7aeM7TYM3Wq+Z77P4u7mU/0NZweZbcqPD0aeSigs5F08A088n8pB1dduxEOlOi iTqwUP8eUwhvK/yUA75jc05V83obLzRh3S873rZorGyLCAG20ACiPjoz6Io4CmtIuIXs RPddWOzBGlC2T7debVD3Oe/eaUGPzioJjg4Q3jVQ8aLEb1JIqVOXeaqps7c5m/UHObsT S62g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Hku9hzULfu2vnc0Wh7cMqLOPbVEx5+yFwXP5JwjGcxA=; b=QGho6dseoDJ4WKGK0eCoUCXeph3NaYySGSE9AdOzl6yJ2w272Q8ukSvDLPb6HsXtQo 2tCBPZ3ot5KtzxzZ8hqXgY/6GxRdf9sOgM4KmQ2jXUa80WCfsCdrM2aZ0eYMpgGoWhnr snu5/MDcjJ3iNo2eEJIBM+vC0wEXDbrIDqA/AmEFX1FB0f3jse1ks988kSMlMV9aG0cR ALyDnKtAuEEHR2Y3oitqT3lkFDsiMEShZjC6oWJW9hKAsDvJSn/Gyxffq/F9q24RyRjB CPLRlXKiXiPbjU31mM+PXgnk+N7LsSSfPhUOnjiCl1zE+IPNVNZsuVlITH3bxlwQvQVs UNTg==
X-Gm-Message-State: AEkooutkaq/eDleRlfjkpJoKBFiSRe+3+Qai3au+kQ1S11HHu9xt7OrLQLdwVMpwby1RB21x8ecl/crZDES7hQ==
X-Received: by 10.13.214.214 with SMTP id y205mr15436968ywd.209.1471850697672;  Mon, 22 Aug 2016 00:24:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.197.140 with HTTP; Mon, 22 Aug 2016 00:24:57 -0700 (PDT)
From: Pieter De Rycke 
Date: Mon, 22 Aug 2016 09:24:57 +0200
Message-ID: 
To: "Oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c0758b2ff4e30053aa3f11c
Archived-At: 
X-Mailman-Approved-At: Tue, 23 Aug 2016 08:13:41 -0700
Subject: [OAUTH-WG] Redirect to STS
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, 22 Aug 2016 07:25:34 -0000

--94eb2c0758b2ff4e30053aa3f11c
Content-Type: text/plain; charset=UTF-8

Hello,

This might be a stupid question, but why is the redirect  happening in
OAuth2 spec (+ SAML previously) to the STS login page for cross domain SSO?
Our marketing department is against this redirect as it means that users
are jumping out of the e-commerce shopping flow. They would prefer a login
mechanism in which the login page remains embedded in the e-commerce
websites. Having flexible in login options is not necessary for us. We do
not expect to move away from username/password anytime soon.

We are thinking about an embedded login page, that does a HTTP POST to the
STS (to have the cross domain SSO cookies), but render the login form
within the ecommerce website. Was there any good reason why the OAuth2/SAML
specs are redirecting to an STS hosted page, except flexibility in login
options and the STS as trusted authentication system. We are considering
such a custom solution, but at the same we would to be sure that we are not
missing some important security aspects that might make our authentication
solution vulnerable.

Kind regards,
Pieter

--94eb2c0758b2ff4e30053aa3f11c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


He=
llo,
This might be a stupid question, but why is the redirec=
t=C2=A0 happening in OAuth2 spec (+ SAML previously) to the STS login page =
for cross domain SSO? Our marketing department is against this redirect as =
it means that users are jumping out of the e-commerce shopping flow. They w=
ould prefer a login mechanism in which the login page remains embedded in t=
he e-commerce websites. Having flexible in login options is not necessary f=
or us. We do not expect to move away from username/password anytime soon.
We are thinking about an embedded login page, that does a HTT=
P POST to the STS (to have the cross domain SSO cookies), but render the lo=
gin form within the ecommerce website. Was there any good reason why the OA=
uth2/SAML specs are redirecting to an STS hosted page, except flexibility i=
n login options and the STS as trusted authentication system. We are consid=
ering such a custom solution, but at the same we would to be sure that we a=
re not missing some important security aspects that might make our authenti=
cation solution vulnerable.
Kind regards,
Pieter


--94eb2c0758b2ff4e30053aa3f11c--


From nobody Tue Aug 23 12:54:20 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE6012D820 for ; Tue, 23 Aug 2016 12:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.259
X-Spam-Level: 
X-Spam-Status: No, score=-1.259 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPdx_kcvizGz for ; Tue, 23 Aug 2016 12:54:16 -0700 (PDT)
Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 7DD2E12DA57 for ; Tue, 23 Aug 2016 12:54:16 -0700 (PDT)
Received: by mail-yw0-x230.google.com with SMTP id z8so79053515ywa.1 for ; Tue, 23 Aug 2016 12:54:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wZXzkAvhiWUbqrI5MLte8UU+gOPMzWwLXK2gWwRiXrk=; b=JIkPD1sUMgsPZnbAbq6vji86/W6lEKy9KzoaEJch3WqxE8QP1GHyyBqWqTFcWYrvBU 34RT44qVaiilawQIr7roYxbw3EjMHTtu4t1iLdghmjmHggMuKAHTsGdC3foLAx8E0b4q tUT/3Jvn1L7yg1kuGjvlBjOuzEtuHr2ffVxArxg0rTNeM8TlGzKqRqDGlzfOR3Up9vnP jbYAB+xN+ZLAmQhfpMkgHhp6Sa9HvD+uiuigfsYvieLKQDq9mbhKlH27IiDRFkkvWrpP v/uXuJRmdwbvTGQ77C+tCSkZyxepmJsiZva1PcZ7dLyhpZ8X3PJDx/p/2Cipse+3JLu5 kFqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wZXzkAvhiWUbqrI5MLte8UU+gOPMzWwLXK2gWwRiXrk=; b=STG0tqJniyMk/u0KRPrUjrzGnIGvZ5/t2TJN76Oq7oOBlfcc2gIzmo7zQS8aeLwerX slk0KvB5Sht3U2ERaE2aNLbHVA97VrmAJaU7BTpOOPOxb8iJ1qaBxFG0sq+DDitQ/59f jp0iijL3I/kZ1hCA/zuiZNVMWZsHwfbQ8P8QxgkWc//Q2saxmtOV440Xyxo2Vq0dthfa tgY2XTn+ixoNRpgfb29pVHK0UXiznRVpENccEFJftZEo2rZRxk2HbZa2Cx2K/gUPqb8s QoUsMtMwVGzMJNMzeaaOMm0swOQXYrX/nYh+TQ1y210a09oYLk+88y5sgq6utn32nB7m mrwQ==
X-Gm-Message-State: AEkoout6GTAPg+mdl3I7PzPn/4ZEuCZR7ejewOoYbteb6x5H2eGqeLruRtcgcEL3d2gAzSPIbYBfWQcqwsqFeEs/
X-Received: by 10.129.109.14 with SMTP id i14mr22405458ywc.4.1471982055430; Tue, 23 Aug 2016 12:54:15 -0700 (PDT)
MIME-Version: 1.0
References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net>    <57BC5F52.5040704@lodderstedt.net>
In-Reply-To: <57BC5F52.5040704@lodderstedt.net>
From: William Denniss 
Date: Tue, 23 Aug 2016 19:54:05 +0000
Message-ID: 
To: Anthony Nadalin , Brian Campbell ,  Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=001a114db696882d95053ac287a0
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
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, 23 Aug 2016 19:54:19 -0000

--001a114db696882d95053ac287a0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

+1 to adopt.

I would like us to develop a unified approach and merge the current drafts.

On Tue, Aug 23, 2016 at 7:58 AM Torsten Lodderstedt 
wrote:

> +1
>
> I would also propose to focus use of token binding to detect replay of
> tokens (access, refresh, code)
>
>
> Am 22.08.2016 um 23:02 schrieb Brian Campbell:
>
> I agree with Tony, if I understand what he's saying.
> https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
> 
> was largely a straw-man to get the conversation started. But after talkin=
g
> with people in Berlin, reviewing Dirk's document, and thinking about it
> some more - it's not clear that PKCE is a great fit for token binding the
> authorization code.
>
> Token binding the authorization code is, I think, something we want to
> account for.  But using/extending PKCE might not be the way to go about i=
t.
> And whatever approach we land on should probably be just one part of the
> larger document on OAuth 2.0 Token Binding.
>
> On Tue, Aug 16, 2016 at 3:26 PM, Anthony Nadalin 
> wrote:
>
>> I=E2=80=99m OK with the
>> https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
>> 
>> but not sure that
>> https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
>> 
>> is a good starting point as we would want a more generic solution for Po=
P
>> tokens in general
>>
>>
>>
>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian
>> Campbell
>> *Sent:* Tuesday, August 16, 2016 11:45 AM
>> *To:* Hannes Tschofenig 
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
>>
>>
>>
>> Just a friendly reminder that the 'deadline' for this call for adoption
>> is tomorrow.
>>
>>
>> According to the minutes from Berlin
>> ,
>> 13 people were in favor of adopting OAuth 2.0 Token Binding and 0 were
>> against.
>>
>>
>>
>> On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig <
>> hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> this is the call for adoption of the 'OAuth 2.0 Token Binding' document
>> bundle* following the positive call for adoption at the recent IETF
>> meeting in Berlin.
>>
>> Here are the links to the documents presented at the last IETF meeting:
>> https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
>> 
>> https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
>> 
>>
>> Please let us know by August 17th whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>>
>> Ciao
>> Hannes & Derek
>>
>> *: We will find out what the best document structure is later, i.e.,
>> whether the content should be included in one, two or multiple documents=
.
>>
>>
>> _______________________________________________
>> 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 list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001a114db696882d95053ac287a0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1 to adopt. 

I would like us to=
 develop a unified approach and merge the current drafts.

On Tue, Aug 23, 2016 at 7:58 AM Torsten=
 Lodderstedt <torsten@lodderstedt.net> wrote:

 =20
   =20
 =20
  

    +1 

    

    I would also propose to focus use of token binding to detect replay
    of tokens (access, refresh, code)


    

    
Am 22.08.2016 um 23:02 schrieb Brian
      Campbell:

    

    

      
I agree with Tony, if I understand what he's
        saying. https://tools.ietf.org/html/d=
raft-campbell-oauth-tbpkce-00
        was largely a straw-man to get the conversation started. But
        after talking with people in Berlin, reviewing Dirk's document,
        and thinking about it some more - it's not clear that PKCE is a
        great fit for token binding the authorization code. 

        

        Token binding the authorization code is, I think, something we
        want to account for.=C2=A0 But using/extending PKCE might not be th=
e
        way to go about it. And whatever approach we land on should
        probably be just one part of the larger document on OAuth 2.0
        Token Binding. 

      

      


        
On Tue, Aug 16, 2016 at 3:26 PM,
          Anthony Nadalin <tonynad@microsoft.com>
          wrote:

          

            

              

                
I=E2=80=99m
                    OK with the
                  https://tools.=
ietf.org/html/draft-jones-oauth-token-binding-00
                  but not sure that 
                    https://tools.ietf.org/html/draft-campbell-oauth-tbpkce=
-00
                  is a good starting point as we would want a more
                  generic solution for PoP tokens in general

                  

                  

                
=C2=A0

                
                
From:
                    OAuth [mailto:oauth-bounces@ietf.org]
                    On Behalf Of Brian Campbell

                    Sent: Tuesday, August 16, 2016 11:45 AM
                      To: Hannes Tschofenig <hannes.tschofenig@gmx.net>

                      Cc: oauth@ietf.org

                    Subject: Re: [OAUTH-WG] Call for
                    adoption: Token Binding for OAuth 2.0

                

                  

                    
=C2=A0

                    

                      
Just a friendly reminder that
                        the 'deadline' for this call for adoption i=
s
                        tomorrow.
                      

                      

                        


                          According to the 
                            minutes from Berlin, 13 people were in
                          favor of adopting OAuth 2.0 Token Binding and
                          0 were against.
                        

                      

                    

                    

                      
=C2=A0

                      

                        
On Wed, Aug 3, 2016 at 1:45
                          AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>
                          wrote:

                        

                          
Hi all,

                            

                            this is the call for adoption of the 'OAuth
                            2.0 Token Binding' document

                            bundle* following the positive call for
                            adoption at the recent IETF

                            meeting in Berlin.

                            

                            Here are the links to the documents
                            presented at the last IETF meeting:

                            https://too=
ls.ietf.org/html/draft-jones-oauth-token-binding-00

                            https://tools.iet=
f.org/html/draft-campbell-oauth-tbpkce-00

                            

                            Please let us know by August 17th whether
                            you accept / object to the

                            adoption of this document as a starting
                            point for work in the OAuth

                            working group.

                            

                            Ciao

                            Hannes & Derek

                            

                            *: We will find out what the best document
                            structure is later, i.e.,

                            whether the content should be included in
                            one, two or multiple documents.

                            

                            

                            _______________________________________________=


                            OAuth mailing list

                            OAuth@ietf.org

                            https://www.ietf.org/m=
ailman/listinfo/oauth

                        

                      

                      
=C2=A0

                    

                  

                

              

            

          

        

        

      

      

      

      

      
_______________________________________________
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




--001a114db696882d95053ac287a0--


From nobody Tue Aug 23 13:22:45 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619DB12DAA2 for ; Tue, 23 Aug 2016 13:22:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.611
X-Spam-Level: 
X-Spam-Status: No, score=-0.611 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] 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 j1AibMoFqHQh for ; Tue, 23 Aug 2016 13:22:40 -0700 (PDT)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d: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 6005E12DABC for ; Tue, 23 Aug 2016 13:22:40 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id t7so118223372qkh.1 for ; Tue, 23 Aug 2016 13:22:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=K65DGCnbU72vBT2dZQY9jfobG8I42BT7nsYbHWjy4n0=; b=LBFl6tWiUHXqZgnudjF5ngm+NdE4LM2OGAEJTzmZrnx4YBUG2IqpQ1Mcag7bXxJ4EO As8K4XuKSZus2ghhTw5eA3w/iW6OrgIgYLLW2yCj0gKEvA2hX9GS1O2lT0y9cjHzmt9D nIISxb9F0IjtnkVIBr5boGWl6nNz3EAx9uX+29lJlohCmUbrYLwEzg+5F1H2DvLOaxnb /TQuNgJR3b00RB0u7p0tmlkUpvCcyL+NJVs+rMlUKBMkZvJodmqIIBxQpF7TwPWOLaXS p+U5ZExIZbaNfbxFcb5THeO67dIY2qm3faGiG8EtfgrhHjdotjQ10OWeuM5gqKy/w0dk eIVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=K65DGCnbU72vBT2dZQY9jfobG8I42BT7nsYbHWjy4n0=; b=cLjPVhz4UGHuVkfrUOkseApDNJRIQnYsTe37B5+aw4GMqwIQOZsDjo//CMDHl3MkYu SjhiF/teAHLZbguWODf9ygEcVLWD2XGr+6YIkZyzCQeoT7HVxAiPlh0Ymi/kqwKQ5Hhw 7RkxwczE3lMsJ/gWlMQtYAdxj4JMNuEwQxqR1AwdWgHAXOyY1+NNNMZJfMbfwjER7rtT Bd8USc67qGhI48M0qlwxMFYCGVg+DP0SXQNe4VEmiHoIZwkct3qt48wAw8cVeVUNKHGb KwTA1hyoE10x36m/yxjx7Gcek1j/N8RPf+1WaStKNhFxMDQNUJhfIuAa79/pivD+Pa/s vpOA==
X-Gm-Message-State: AEkoouuEiCqthv9g8bRzp6gkqbtjoXamJ9Mc2Xq+TnYrF3+qRepC+rNB87V4m8w/AjUyDI6W
X-Received: by 10.55.141.131 with SMTP id p125mr31970859qkd.132.1471983759297;  Tue, 23 Aug 2016 13:22:39 -0700 (PDT)
Received: from [192.168.8.102] ([181.201.31.235]) by smtp.gmail.com with ESMTPSA id k65sm2731761qkf.7.2016.08.23.13.22.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Aug 2016 13:22:38 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E5ADE5F2-6869-4605-A6E1-1C54891184CE"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: John Bradley 
In-Reply-To: 
Date: Tue, 23 Aug 2016 17:22:33 -0300
Message-Id: 
References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net>    <57BC5F52.5040704@lodderstedt.net> 
To: William Denniss 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
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, 23 Aug 2016 20:22:43 -0000

--Apple-Mail=_E5ADE5F2-6869-4605-A6E1-1C54891184CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes I think merging the drafts and not reusing PKCE is the correct path.

Protection for code in the browser redirect also needs to be added to =
fully protect the whole flow.

John B.
> On Aug 23, 2016, at 4:54 PM, William Denniss  =
wrote:
>=20
> +1 to adopt.=20
>=20
> I would like us to develop a unified approach and merge the current =
drafts.
>=20
> On Tue, Aug 23, 2016 at 7:58 AM Torsten Lodderstedt =
> wrote:
> +1=20
>=20
> I would also propose to focus use of token binding to detect replay of =
tokens (access, refresh, code)
>=20
>=20
> Am 22.08.2016 um 23:02 schrieb Brian Campbell:
>> I agree with Tony, if I understand what he's saying. =
https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 =
 =
was largely a straw-man to get the conversation started. But after =
talking with people in Berlin, reviewing Dirk's document, and thinking =
about it some more - it's not clear that PKCE is a great fit for token =
binding the authorization code.=20
>>=20
>> Token binding the authorization code is, I think, something we want =
to account for.  But using/extending PKCE might not be the way to go =
about it. And whatever approach we land on should probably be just one =
part of the larger document on OAuth 2.0 Token Binding.=20
>>=20
>> On Tue, Aug 16, 2016 at 3:26 PM, Anthony Nadalin =
> wrote:
>> I=E2=80=99m OK with the =
https://tools.ietf.org/html/draft-jones-oauth-token-binding-00 =
 but not sure that =
https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 =
 =
is a good starting point as we would want a more generic solution for =
PoP tokens in general
>>=20
>>=20
>> =C2=A0 <>
>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of Brian Campbell
>> Sent: Tuesday, August 16, 2016 11:45 AM
>> To: Hannes Tschofenig < =
hannes.tschofenig@gmx.net =
>
>> Cc: oauth@ietf.org 
>> Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth =
2.0
>>=20
>> =20
>> Just a friendly reminder that the 'deadline' for this call for =
adoption is tomorrow.
>>=20
>>=20
>> According to the minutes from Berlin =
, 13 people were in favor of adopting OAuth 2.0 Token Binding and 0 =
were against.
>>=20
>> =20
>> On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig < =
hannes.tschofenig@gmx.net =
> wrote:
>>=20
>> Hi all,
>>=20
>> this is the call for adoption of the 'OAuth 2.0 Token Binding' =
document
>> bundle* following the positive call for adoption at the recent IETF
>> meeting in Berlin.
>>=20
>> Here are the links to the documents presented at the last IETF =
meeting:
>> https://tools.ietf.org/html/draft-jones-oauth-token-binding-00 =

>> https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00 =

>>=20
>> Please let us know by August 17th 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
>> *: We will find out what the best document structure is later, i.e.,
>> whether the content should be included in one, two or multiple =
documents.
>>=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
> _______________________________________________
> 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=_E5ADE5F2-6869-4605-A6E1-1C54891184CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes I think merging the drafts and not reusing PKCE is the =
correct path.

Protection for code in the browser redirect also needs to be =
added to fully protect the whole flow.

John B.
On =
Aug 23, 2016, at 4:54 PM, William Denniss <wdenniss@google.com>=
 wrote:

+1 to adopt. 

I would like us to develop a unified approach and merge the =
current drafts.

On Tue, Aug 23, 2016 at 7:58 AM Torsten =
Lodderstedt <torsten@lodderstedt.net> wrote:

 =20
   =20
 =20
  

    +1 

    

    I would also propose to focus use of token binding to detect replay
    of tokens (access, refresh, code)


    

    
Am =
22.08.2016 um 23:02 schrieb Brian
      Campbell:

    

    

      
I agree with Tony, if I understand =
what he's
        saying. https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
        was largely a straw-man to get the conversation started. But
        after talking with people in Berlin, reviewing Dirk's document,
        and thinking about it some more - it's not clear that PKCE is a
        great fit for token binding the authorization code. 

        

        Token binding the authorization code is, I think, something we
        want to account for.  But using/extending PKCE might not be =
the
        way to go about it. And whatever approach we land on should
        probably be just one part of the larger document on OAuth 2.0
        Token Binding. 

      

      


        
On Tue, Aug 16, 2016 at 3:26 PM,
          Anthony Nadalin <tonynad@microsoft.com>
          wrote:

          

            
=

              
I=E2=80=99m
                    OK with the
                  https://tools.ietf.org/html/draft-jones-oauth-token-binding-00<=
/a>
                  but not sure that 
                    =
https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
                  is a good starting point as we would want a more
                  generic solution for PoP tokens in general

                  

                  
 

                
From:
                    OAuth [mailto:oauth-bounces@ietf.org]
                    On Behalf Of Brian Campbell

                    Sent: Tuesday, August 16, 2016 =
11:45 AM

                      To: Hannes Tschofenig <hannes.tschofenig@gmx.net>

                      Cc: oauth@ietf.org

                    Subject: Re: [OAUTH-WG] =
Call for
                    adoption: Token Binding for OAuth 2.0

                

                  
 

                    
Just a =
friendly reminder that
                        the 'deadline' for this call for adoption is
                        tomorrow.
                      

                      


                          According to the 
                            minutes from Berlin, 13 people were in
                          favor of adopting OAuth 2.0 Token Binding and
                          0 were against.
                        

                      

                    

                    
 

                      
On Wed, Aug =
3, 2016 at 1:45
                          AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>
                          wrote:

                        
Hi all,

                            

                            this is the call for adoption of the 'OAuth
                            2.0 Token Binding' document

                            bundle* following the positive call for
                            adoption at the recent IETF

                            meeting in Berlin.

                            

                            Here are the links to the documents
                            presented at the last IETF meeting:

                            https://tools.ietf.org/html/draft-jones-oauth-token-binding-00<=
/a>

                            https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00<=
br class=3D"">
                            

                            Please let us know by August 17th whether
                            you accept / object to the

                            adoption of this document as a starting
                            point for work in the OAuth

                            working group.

                            

                            Ciao

                            Hannes & Derek

                            

                            *: We will find out what the best document
                            structure is later, i.e.,

                            whether the content should be included in
                            one, two or multiple documents.
=

                            

                            

                            =
_______________________________________________

                            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

=

--Apple-Mail=_E5ADE5F2-6869-4605-A6E1-1C54891184CE--


From nobody Tue Aug 23 14:01:45 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88C212D6A1 for ; Tue, 23 Aug 2016 14:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.611
X-Spam-Level: 
X-Spam-Status: No, score=-0.611 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] 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 uthucIif4CPN for ; Tue, 23 Aug 2016 14:01:40 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d: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 7B3D912D0AF for ; Tue, 23 Aug 2016 14:01:40 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id l2so119335908qkf.3 for ; Tue, 23 Aug 2016 14:01:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3ZBvMRBr/62CPxaajBOmzJOURmF2ob4Fe3DcFy3i3IE=; b=aHswMhhgv288VySh+KbzHTZLA4SjBwTkro/0FzLors4LWphvlxpfepb2LVtRPKod8q WLUIV170/wBCf5hQYcu+OTywB4OpNinbrKoxfKEuW+dgX+glzgDREJnQ7F/DzgYZqPzA eWSAysk6aSyenSWZUhwv0i1OdGRdSNjQ2RkwDbJ/Vstts3gTbWOIMCkXqYcv2n95kKMz hAWZ47O/Zx7r+J13zfx6DXi+Y0YW2wWVZveaPxAhZbmkDKpxTx/gYERF8nYFeGAEX25g 08hY0aKB4YFbcWm7ItCccgSyAdEh9xu683oXFOLc6Pjig6PS5ovByu7rN4Ej0vE8eHlc pFkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3ZBvMRBr/62CPxaajBOmzJOURmF2ob4Fe3DcFy3i3IE=; b=V+8Kk7hEW+IgeL2/7rSIh4RzxVMeKkpD9dX5s1D4Xl39OFpItRB4/retqkOy014zow mLx3sZ/qxs1VTtnUxQuo+PZeckcZkv5AvrxDFqT/l683U8Lb9SiEFhdgo6XKhI/iVxY4 hK9+CjJVX4InN/xtqkSdk9wKwMj50iRgJwZCRkHUvqSxSDz4z7MUJdn1268C/yKw4OMv kqjkxnzX26SjX6tpwMkBPpI7zQQFcvZzTwPXTzGaPttcTy88VKy+ClrO2MCcXw+BiDty hBbIwqXXOkn1Ab3TG1+Sp/bmAR+0oCxAgUVFmiURIOlQNWI1rrJ15oQhDUzIBbrO4SiX SfQg==
X-Gm-Message-State: AE9vXwODCVvenMUZnCrAlu6/jtDyX0QshATb219d5qDakkHMhbnFyB66TIUkYGfly0nxxAmk/MrQv2EF+XUPS5nx
X-Received: by 10.55.42.76 with SMTP id q73mr2645678qkh.250.1471986099409; Tue, 23 Aug 2016 14:01:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.105.3 with HTTP; Tue, 23 Aug 2016 14:01:38 -0700 (PDT)
X-Originating-IP: [181.201.31.235]
In-Reply-To: 
References: <33052033-0992-ceb8-4390-6837017b140e@gmx.net>    <57BC5F52.5040704@lodderstedt.net> 
From: John Bradley 
Date: Tue, 23 Aug 2016 18:01:38 -0300
Message-ID: 
To: William Denniss 
Content-Type: multipart/alternative; boundary=001a1149611a92324d053ac37845
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
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, 23 Aug 2016 21:01:45 -0000

--001a1149611a92324d053ac37845
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes I think merging the drafts and not reusing PKCE is the correct path.

Protection for code in the browser redirect also needs to be added to fully
protect the w

On Aug 23, 2016, at 4:54 PM, William Denniss  wrote:

+1 to adopt.

I would like us to develop a unified approach and merge the current drafts.

On Tue, Aug 23, 2016 at 7:58 AM Torsten Lodderstedt 
wrote:

> +1
>
> I would also propose to focus use of token binding to detect replay of
> tokens (access, refresh, code)
>
>
> Am 22.08.2016 um 23:02 schrieb Brian Campbell:
>
> I agree with Tony, if I understand what he's saying.
> https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
> 
> was largely a straw-man to get the conversation started. But after talkin=
g
> with people in Berlin, reviewing Dirk's document, and thinking about it
> some more - it's not clear that PKCE is a great fit for token binding the
> authorization code.
>
> Token binding the authorization code is, I think, something we want to
> account for.  But using/extending PKCE might not be the way to go about i=
t.
> And whatever approach we land on should probably be just one part of the
> larger document on OAuth 2.0 Token Binding.
>
> On Tue, Aug 16, 2016 at 3:26 PM, Anthony Nadalin 
> wrote:
>
>> I=E2=80=99m OK with the https://tools.ietf.org/html/draft-jones-oauth-to=
ken-
>> binding-00
>> 
>> but not sure that https://tools.ietf.org/html/
>> draft-campbell-oauth-tbpkce-00
>> 
>> is a good starting point as we would want a more generic solution for Po=
P
>> tokens in general
>>
>>
>>
>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *Brian
>> Campbell
>> *Sent:* Tuesday, August 16, 2016 11:45 AM
>> *To:* Hannes Tschofenig < 
>> hannes.tschofenig@gmx.net>
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Call for adoption: Token Binding for OAuth 2.0
>>
>>
>> Just a friendly reminder that the 'deadline' for this call for adoption
>> is tomorrow.
>>
>>
>> According to the minutes from Berlin
>> ,
>> 13 people were in favor of adopting OAuth 2.0 Token Binding and 0 were
>> against.
>>
>>
>> On Wed, Aug 3, 2016 at 1:45 AM, Hannes Tschofenig <
>> hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> this is the call for adoption of the 'OAuth 2.0 Token Binding' document
>> bundle* following the positive call for adoption at the recent IETF
>> meeting in Berlin.
>>
>> Here are the links to the documents presented at the last IETF meeting:
>> https://tools.ietf.org/html/draft-jones-oauth-token-binding-00
>> 
>> https://tools.ietf.org/html/draft-campbell-oauth-tbpkce-00
>> 
>>
>> Please let us know by August 17th whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>>
>> Ciao
>> Hannes & Derek
>>
>> *: We will find out what the best document structure is later, i.e.,
>> whether the content should be included in one, two or multiple documents=
.
>>
>>
>> _______________________________________________
>> 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 list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--001a1149611a92324d053ac37845
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Yes I thi=
nk merging the drafts and not reusing PKCE is the correct path.

Protection for code in the browser redirect also needs to be added =
to fully protect the w
On Aug 23, 2016, at 4:54 PM, William Denniss <wdenniss@google.com&g=
t; wrote:

+1 to adopt. 
I would like us to develop a unified approach and merge the current d=
rafts.

On Tue, Aug 23,=
 2016 at 7:58 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=


 =20
   =20
 =20
  

    +1 

    

    I would also propose to focus use of token binding to detect replay
    of tokens (access, refresh, code)


    

    
Am 22.08.2016 um 23:02 schrieb Brian
      Campbell:

    

    

      
I agree with Tony, if I understand what he's
        saying. https://tools.ietf.org/html/<=
wbr>draft-campbell-oauth-tbpkce-00
        was largely a straw-man to get the conversation started. But
        after talking with people in Berlin, reviewing Dirk's document,
        and thinking about it some more - it's not clear that PKCE is a
        great fit for token binding the authorization code. 

        

        Token binding the authorization code is, I think, something we
        want to account for.=C2=A0 But using/extending PKCE might not be th=
e
        way to go about it. And whatever approach we land on should
        probably be just one part of the larger document on OAuth 2.0
        Token Binding. 

      

      


        
On Tue, Aug 16, 2016 at 3:26 PM,
          Anthony Nadalin <tonynad@microsoft.com>
          wrote:

          

            

              
I=E2=80=99m
                    OK with the
                  https://tools.=
ietf.org/html/draft-jones-oauth-token-binding-00
                  but not sure that 
                    https://tools.ietf.org/html/draft-campbell-oauth-t=
bpkce-00
                  is a good starting point as we would want a more
                  generic solution for PoP tokens in general

                  

                  
=C2=A0

                
From:
                    OAuth [mailto:oauth-bounces@ietf.org]
                    On Behalf Of Brian Campbell

                    Sent: Tuesday, August 16, 2016 11:45 AM
                      To: Hannes Tschofenig <hannes.tschofenig@gmx.net>

                      Cc: oauth@ietf.org

                    Subject: Re: [OAUTH-WG] Call for
                    adoption: Token Binding for OAuth 2.0

                

                  
=C2=A0

                    
Just a friendly reminder th=
at
                        the 'deadline' for this call for adoption i=
s
                        tomorrow.
                      

                      


                          According to the 
                            minutes from Berlin, 13 people were in
                          favor of adopting OAuth 2.0 Token Binding and
                          0 were against.
                        

                      

                    

                    
=C2=A0

                      
On Wed, Aug 3, 2016 at 1:=
45
                          AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>
                          wrote:

                        
Hi all,

                            

                            this is the call for adoption of the 'OAuth
                            2.0 Token Binding' document

                            bundle* following the positive call for
                            adoption at the recent IETF

                            meeting in Berlin.

                            

                            Here are the links to the documents
                            presented at the last IETF meeting:

                            https://too=
ls.ietf.org/html/draft-jones-oauth-token-binding-00

                            https://tools.iet=
f.org/html/draft-campbell-oauth-tbpkce-00

                            

                            Please let us know by August 17th whether
                            you accept / object to the

                            adoption of this document as a starting
                            point for work in the OAuth

                            working group.

                            

                            Ciao

                            Hannes & Derek

                            

                            *: We will find out what the best document
                            structure is later, i.e.,

                            whether the content should be included in
                            one, two or multiple documents.

                            

                            

                            __________________________________________=
_____

                            OAuth mailing list

                            OAuth@ietf.org

                            https://www.ietf.org/m=
ailman/listinfo/oauth

                        

                      
=C2=A0

                    

                  

                

              

            

          

        

        

      

      

      

      

      
_______________________________________________
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



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



--001a1149611a92324d053ac37845--


From nobody Fri Aug 26 10:31:00 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E841F12D14F for ; Fri, 26 Aug 2016 10:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5XNPRY3Cpb4 for ; Fri, 26 Aug 2016 10:30:57 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 7FE4F12D0C2 for ; Fri, 26 Aug 2016 10:30:57 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id g62so2638991ith.1 for ; Fri, 26 Aug 2016 10:30:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/+Wp1fMyDraqr8r9PpAf4DB+HDB4DXzT/tuD1wfWgy4=; b=EYGX/4v9X9o5DZAmJ4FW0TyeXElQKeygqx3jGrYQ7FHQ4QXVwxqiuhyncapzSXXzQ9 v3m5+UE/mIpi+laa+lRSQebBUAfJK9Q23YjN3Swmb2GQZZrH1y8oxYppcigWErGw6aDg nQP/mg9ALQLp+LGcwsiKpcE6MWGD3RDsBMN88=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/+Wp1fMyDraqr8r9PpAf4DB+HDB4DXzT/tuD1wfWgy4=; b=DT28Ep7IcS45QBPSxROTMZ8jg25/EI4SRznBMpFJolLEUMTa4S+O7vIZJR/lUMpMXV 7Nyd4GsGxehf5MrZqYelWc00uJcqOTF25Z7wCnsdGn1sEExqF0cy/BUL70DBmzx1YBVG +3WqMSHmodIh0qA3612mAHSYBoUkEaL9MyebBBgmE9XGQVHlvCOWIktN4am02+xJZ24c ZSkCPTZ3Lzx8Dk6uo0b4qCIQny0SdAbdZr6jAo5VLp6+Q372u1mabJEL+D6yBzY4Gs+j mjj0V0MHVeA7tNljFJFQkRQO4Dhx3clDxFWeo2PKPJuNxfaOb/BjYMsm39kFrzQKGTX/ 77jw==
X-Gm-Message-State: AE9vXwNYNVkuXByTZNjYxPMy52hifAKCC9aAltB7dAF4iG8SNzyVkAZBmfbSJGcUZBYYR3ZXhK2sDH3atqhoazPQ
X-Received: by 10.36.84.135 with SMTP id t129mr1479ita.63.1472232656659; Fri, 26 Aug 2016 10:30:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.114.20 with HTTP; Fri, 26 Aug 2016 10:30:26 -0700 (PDT)
In-Reply-To: 
References: 
From: Brian Campbell 
Date: Fri, 26 Aug 2016 11:30:26 -0600
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=001a1143d9228711c5053afce0b6
Archived-At: 
Subject: Re: [OAUTH-WG] Following up on token exchange use case
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, 26 Aug 2016 17:30:59 -0000

--001a1143d9228711c5053afce0b6
Content-Type: text/plain; charset=UTF-8

Looking for two things here:

1) Any objections to removing the want_composite request parameter? Please
explain, if so. I plan to remove it in the next draft barring an outpouring
of support to keep it.

2) Tony to explain his use case and describe what changes would be needed
to accommodate it.

On Mon, Aug 1, 2016 at 2:00 PM, Brian Campbell 
wrote:

> During the meeting in Berlin Tony voiced concern about a use case he had
> for token exchange. Honestly, it's still not entirely clear to me what that
> use case is or what would need to change in support of it. I'd like to
> better understand the use case and see if it's something that can
> reasonably be accommodated with Token Exchange. During the meeting Tony
> referred back to an earlier email where he said, "want_composite is not
> really the effect we are looking for since it provides for a single token,
> the use case we have is where you want the ability to use the subject_token
> and the actor_token in combination and not as a composite of only the
> claims."
>
> The want_composite parameter came about during some iterative work on the
> document (between I-D publications) last year. At first the client could
> express that it wanted a composite token, one containing delegation
> semantics, with the inclusion of the actor_token parameter. One of the
> other editors suggested, however, that the actor_token token might be
> necessary for authorization in cases even when the client wasn't asking for
> a composite token and that placing the desire for delegation semantics on
> it was overloading the parameter too much. I introduced the want_composite
> parameter to give the client such a signal independent of the actor_token
> parameter. My (admittedly incomplete) understanding of WS-Trust is that the
> client/requester can make such an indication and I was trying to follow
> that model. However, I'm not sure it's needed or even makes much much
> sense. Ultimately it's the server's decision about how to construct the
> issued token and what to include in it. It is the server's policy, not a
> client signal, which makes the determination. So the want_composite
> parameter is really just noise that makes the spec longer. And, from the
> quote above, seems might also lead some readers to incorrect conclusions
> about what can and cannot be returned in a token exchange.
>
> I'd propose then that the want_composite parameter be dropped from the
> document.
>
>

--001a1143d9228711c5053afce0b6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Looking for two things here:

1) Any=
 objections to removing the want_composite request parameter? Please explai=
n, if so. I plan to remove it in the next draft barring an outpouring of su=
pport to keep it.

2) Tony to explain his use case and describe=
 what changes would be needed to accommodate it. 

On Mon, Aug 1, 2016 at 2:00 PM, B=
rian Campbell <bcampbell@pingidentity.com> wrote:
During the meeting i=
n Berlin Tony voiced concern about a use case he had for token exchange. Ho=
nestly, it's still not entirely clear to me what that use case is or wh=
at would need to change in support of it. I'd like to better understand=
 the use case and see if it's something that can reasonably be accommod=
ated with Token Exchange. During the meeting Tony referred back to an earli=
er email where he said, "want_composite is not really the effect we ar=
e looking for since it=20
provides for a single token, the use case we have is where you want the=20
ability to use the subject_token and the actor_token in combination and=20
not as a composite of only
 the claims." 

The want_composite parameter came abo=
ut during some iterative work on the document (between I-D publications) la=
st year. At first the client could express that it wanted a composite token=
, one containing delegation semantics, with the inclusion of the actor_toke=
n parameter. One of the other editors suggested, however, that the actor_to=
ken token might be necessary for authorization in cases even when the clien=
t wasn't asking for a composite token and that placing the desire for d=
elegation semantics on it was overloading the parameter too much. I introdu=
ced the want_composite parameter to give the client such a signal independe=
nt of the actor_token parameter. My (admittedly incomplete) understanding o=
f WS-Trust is that the client/requester can make such an indication and I w=
as trying to follow that model. However, I'm not sure it's needed o=
r even makes much much sense. Ultimately it's the server's decision=
 about how to construct the issued token and what to include in it. It is t=
he server's policy, not a client signal, which makes the determination.=
 So the want_composite parameter is really just noise that makes the spec l=
onger. And, from the quote above, seems might also lead some readers to inc=
orrect conclusions about what can and cannot be returned in a token exchang=
e. 

I'd propose then that the want_composite paramete=
r be dropped from the document.=C2=A0 
=C2=A0





--001a1143d9228711c5053afce0b6--


From nobody Sat Aug 27 15:26:14 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C2412D150 for ; Sat, 27 Aug 2016 15:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 WXI2BdK3Fc0g for ; Sat, 27 Aug 2016 15:26:09 -0700 (PDT)
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 87E9112D180 for ; Sat, 27 Aug 2016 15:26:08 -0700 (PDT)
X-AuditID: 12074425-d03ff70000003c9b-f0-57c2137d3be9
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 54.C9.15515.D7312C75; Sat, 27 Aug 2016 18:26:07 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u7RMQ5Mj032401; Sat, 27 Aug 2016 18:26:05 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u7RMQ3dD015687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 27 Aug 2016 18:26:04 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_3AA8670F-8996-444D-9F7D-40D74A56BCEF"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Justin Richer 
In-Reply-To: 
Date: Sat, 27 Aug 2016 18:26:01 -0400
Message-Id: 
References:  
To: Brian Campbell 
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hRV1q0XPhRu8LFdwWL1/5uMFiffvmJz YPJYsuQnk8fdoxdZApiiuGxSUnMyy1KL9O0SuDJ+/5zMWLDBpuLG4fIGxg9GXYycHBICJhId jXPYuxi5OIQE2pgkfs6cyQrhbGSUmLz4OzOE85BJYsKvdawgLcwCCRKTWtazgdi8AnoSm9a/ ZQKxhQXsJXZ0bgSLswmoSkxf0wIW5xQIlHjWfQ0szgIUb1+wEWgoB9AcdYn2ky4QY6wkJs98 wwSxayqjxLcPBxhBEiIC+hK3n4KcB3KqrMSTk4tYJjDyz0JyxiwkZ0DEtSWWLXzNDGFrSuzv Xs6CKa4h0fltIusCRrZVjLIpuVW6uYmZOcWpybrFyYl5ealFuhZ6uZkleqkppZsYQYHN7qK6 g3HOX69DjAIcjEo8vB4/DoYLsSaWFVfmHmKU5GBSEuW9IwIU4kvKT6nMSCzOiC8qzUktPsQo wcGsJMLrLHQoXIg3JbGyKrUoHyYlzcGiJM7bNeNAuJBAemJJanZqakFqEUxWhoNDSYJXC6RR sCg1PbUiLTOnBCHNxMEJMpwHaDgv2PDigsTc4sx0iPwpRkUpcd4wQaCEAEgiozQPrheUeBLe HjZ9xSgO9IowLx9IOw8wacF1vwIazAQ0mOH1fpDBJYkIKakGRkHLU4ITb775fMXzq/b12fP3 33py4njmPc0O4daLfdzuhVE9Mz3jlxUnOL3as+nFBj0Oj5TFL2dFPN2nxHVVdn3xkst+PcoO J/Yl/k3IyWW7E2z3r5aTKU+befWkyqsbRHKvZzxdz/B1y5Puul3Huy/NjKw987XOzVvSQO/V L/fD5x9U2h8qMlNiKc5INNRiLipOBAAoIZGiFwMAAA==
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Following up on token exchange use case
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, 27 Aug 2016 22:26:13 -0000

--Apple-Mail=_3AA8670F-8996-444D-9F7D-40D74A56BCEF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

No objections. Simplification is better, and this spec is already fairly =
convoluted with all the options turned on.

 =E2=80=94 Justin

> On Aug 26, 2016, at 1:30 PM, Brian Campbell =
 wrote:
>=20
> Looking for two things here:
>=20
> 1) Any objections to removing the want_composite request parameter? =
Please explain, if so. I plan to remove it in the next draft barring an =
outpouring of support to keep it.
>=20
> 2) Tony to explain his use case and describe what changes would be =
needed to accommodate it.=20
>=20
> On Mon, Aug 1, 2016 at 2:00 PM, Brian Campbell =
> wrote:
> During the meeting in Berlin Tony voiced concern about a use case he =
had for token exchange. Honestly, it's still not entirely clear to me =
what that use case is or what would need to change in support of it. I'd =
like to better understand the use case and see if it's something that =
can reasonably be accommodated with Token Exchange. During the meeting =
Tony referred back to an earlier email where he said, "want_composite is =
not really the effect we are looking for since it provides for a single =
token, the use case we have is where you want the ability to use the =
subject_token and the actor_token in combination and not as a composite =
of only the claims."=20
>=20
> The want_composite parameter came about during some iterative work on =
the document (between I-D publications) last year. At first the client =
could express that it wanted a composite token, one containing =
delegation semantics, with the inclusion of the actor_token parameter. =
One of the other editors suggested, however, that the actor_token token =
might be necessary for authorization in cases even when the client =
wasn't asking for a composite token and that placing the desire for =
delegation semantics on it was overloading the parameter too much. I =
introduced the want_composite parameter to give the client such a signal =
independent of the actor_token parameter. My (admittedly incomplete) =
understanding of WS-Trust is that the client/requester can make such an =
indication and I was trying to follow that model. However, I'm not sure =
it's needed or even makes much much sense. Ultimately it's the server's =
decision about how to construct the issued token and what to include in =
it. It is the server's policy, not a client signal, which makes the =
determination. So the want_composite parameter is really just noise that =
makes the spec longer. And, from the quote above, seems might also lead =
some readers to incorrect conclusions about what can and cannot be =
returned in a token exchange.=20
>=20
> I'd propose then that the want_composite parameter be dropped from the =
document.=20
> =20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_3AA8670F-8996-444D-9F7D-40D74A56BCEF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

No objections. Simplification is better, and this spec is =
already fairly convoluted with all the options turned on.

 =E2=80=94 =
Justin

On Aug 26, 2016, at 1:30 PM, Brian Campbell =
<bcampbell@pingidentity.com> wrote:

Looking for two things here:

1) Any objections to removing the want_composite =
request parameter? Please explain, if so. I plan to remove it in the =
next draft barring an outpouring of support to keep it.

2) Tony to explain his use case and describe what =
changes would be needed to accommodate it. 

On Mon, =
Aug 1, 2016 at 2:00 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
During the meeting in Berlin Tony voiced =
concern about a use case he had for token exchange. Honestly, it's still =
not entirely clear to me what that use case is or what would need to =
change in support of it. I'd like to better understand the use case and =
see if it's something that can reasonably be accommodated with Token =
Exchange. During the meeting Tony referred back to an earlier email =
where he said, "want_composite is not really the effect we are looking =
for since it=20
provides for a single token, the use case we have is where you want the=20=

ability to use the subject_token and the actor_token in combination and=20=

not as a composite of only
 the claims." 

The =
want_composite parameter came about during some iterative work on the =
document (between I-D publications) last year. At first the client could =
express that it wanted a composite token, one containing delegation =
semantics, with the inclusion of the actor_token parameter. One of the =
other editors suggested, however, that the actor_token token might be =
necessary for authorization in cases even when the client wasn't asking =
for a composite token and that placing the desire for delegation =
semantics on it was overloading the parameter too much. I introduced the =
want_composite parameter to give the client such a signal independent of =
the actor_token parameter. My (admittedly incomplete) understanding of =
WS-Trust is that the client/requester can make such an indication and I =
was trying to follow that model. However, I'm not sure it's needed or =
even makes much much sense. Ultimately it's the server's decision about =
how to construct the issued token and what to include in it. It is the =
server's policy, not a client signal, which makes the determination. So =
the want_composite parameter is really just noise that makes the spec =
longer. And, from the quote above, seems might also lead some readers to =
incorrect conclusions about what can and cannot be returned in a token =
exchange. 

I'd =
propose then that the want_composite parameter be dropped from the =
document.  
 




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

=

--Apple-Mail=_3AA8670F-8996-444D-9F7D-40D74A56BCEF--


From giridharanbtech@gmail.com  Sun Aug 28 14:51:30 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFF612B030 for ; Sun, 28 Aug 2016 14:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vksdj0yx6BET for ; Sun, 28 Aug 2016 14:51:28 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A628512B00A for ; Sun, 28 Aug 2016 14:51:28 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id f189so174282738oig.3 for ; Sun, 28 Aug 2016 14:51:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=6+awIvS3huV/hLWFzsqKHwEyfQokVe2ZXKr+iOmXOgo=; b=DbyDmFOO6BjZFApn1ImfGpgfFmmHnF5fNddD0ApE7AA9nCAQuV3qtsxLhwggx5no5N YgodLJaC9CIzGtMUmTmO78N6S/BOyNt4UVoj9ttHSeFmPNMtHH2g9Uyu/BZZ9R9400pe UeTCCoQBABcbWoOyPbLBXZBWgGpiyHX8OLlu8TYFTobA3o79Dh+7Bs93NH4KEuDiLylp lFshnQDf0YKFW6UEyVBmyVLZ0NVIsEiEXTNx/beJ+3Ah3VnJvyw3uNnzTZUuUmJbxB5a gKpgAN+dLyaO+Pkhx9MSNc0R9d4FDjuMiZKT1Hyir6Waw2j0N7FUdk7byU+2lQFdYD1L 1NVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6+awIvS3huV/hLWFzsqKHwEyfQokVe2ZXKr+iOmXOgo=; b=KFTqW491peCNi54QvNeTWBv1DTzfvHiC2kZ4itxmgjbJ7cbq2g4ELl2+UWu22jzcGW uIvCGNf8PUUsnHZc5kSNlVmpVC94fZFZgsaVf1gsrzBzhL80qGBV6JtUCExTi7E8o6SM kQ0nUzezku2OzOa8UDkZSX1h60NM42/dOY2A0kTeD5gjZY0Xohoe4W7DAlEgMvm0h58Z aJeaoCoELJaU6cK3dMG7B7FgwQRwgYMD+3ctXkV2G2dii7OR72rrFb77WKrQLMqMm+W2 GEN3YaJoOkh+UAt6+lCbb9sK3wM2FgTvNcb+5XzEOHGwRM/epAkaXw8LeN7y5nD3HNt/ IamQ==
X-Gm-Message-State: AE9vXwO4c5Imcoxnfd0lUbA71Umw4mCorzKyFmUcPxFMAq7KQ3GOzCq+x6oN3zL5bUa/tFzOLxkthtP+WbnvWQ==
X-Received: by 10.202.227.84 with SMTP id a81mr8591160oih.57.1472421087885; Sun, 28 Aug 2016 14:51:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.221.69 with HTTP; Sun, 28 Aug 2016 14:51:07 -0700 (PDT)
From: Viruthagiri Thirumavalavan 
Date: Mon, 29 Aug 2016 03:21:07 +0530
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a11408d96e740ed053b28bfc7
Archived-At: 
X-Mailman-Approved-At: Mon, 29 Aug 2016 08:26:50 -0700
Subject: [OAUTH-WG] Can i use domain name for oauth2 client id?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 Aug 2016 21:52:43 -0000

--001a11408d96e740ed053b28bfc7
Content-Type: text/plain; charset=UTF-8

I'm working on a OAuth2 server project. Can I use domain name for
generating client_id ?

Ex: For instance if Google registering an app in my server, then the
client_id will be google.com

Am i allowed to use dots in client_id? Is it wise to use domain name as
client_id ? what are the drawbacks?
Thanks
-- 
Regards,
Giri

--001a11408d96e740ed053b28bfc7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable











I'm working on a OAuth2 server project. =
Can I use domain name for generating client_id ?


Ex: For instance if Google registering an ap=
p in my server, then the client_id will be google.com
Am i allowed =
to use dots in client_id? Is it wise to use domain name as client_id ? what=
 are the drawbacks?
Thanks
-- 
Regards,
Gir=
i




--001a11408d96e740ed053b28bfc7--


From nobody Mon Aug 29 08:57:00 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8529E12D125 for ; Mon, 29 Aug 2016 08:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 zvLnzbxZ-zhj for ; Mon, 29 Aug 2016 08:56:57 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A4312D10B for ; Mon, 29 Aug 2016 08:56:56 -0700 (PDT)
X-AuditID: 1209190d-f27ff70000000d6f-63-57c45b478865
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 B9.3C.03439.74B54C75; Mon, 29 Aug 2016 11:56:55 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u7TFutLN030663; Mon, 29 Aug 2016 11:56:55 -0400
Received: from [10.93.2.174] ([62.237.32.178]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u7TFupM4011730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Aug 2016 11:56:54 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_76546578-EBB3-46C2-B5B4-53ABC26A9B2D"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Justin Richer 
In-Reply-To: 
Date: Mon, 29 Aug 2016 18:56:51 +0300
Message-Id: <50F0DFCB-31D3-47F8-BC0E-3D52383ACECA@mit.edu>
References: 
To: Viruthagiri Thirumavalavan 
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT13WPPhJucPGIlUXbhXssFiffvmJz YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDL2PbzIWPBbruLPtG7mBsanUl2MnBwSAiYS L9+/YOti5OIQEmhjkvgwfSMrhLORUWLhhiNQzmomiRdn1rKDtDALJEhsvbOUGcTmFdCT2LT+ LROILSzgLLHg8U1GEJtNQFVi+poWsDinQKDEsWVPwWwWoPj69g9AcziA5qhLtJ90gRhjJTFl 4QKw8UICARKHXjWDjRcBiq99fpoZ4lJZiScnF7FMYOSfheSKWUiugIhrSyxb+JoZwtaU2N+9 nAVTXEOi89tE1gWMbKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGCAptTkncH 47+7XocYBTgYlXh4LZyOhAuxJpYVV+YeYpTkYFIS5S25czhciC8pP6UyI7E4I76oNCe1+BCj BAezkgjvCn+gct6UxMqq1KJ8mJQ0B4uSOG/XjAPhQgLpiSWp2ampBalFMFkZDg4lCd5rkUCN gkWp6akVaZk5JQhpJg5OkOE8QMM3gdTwFhck5hZnpkPkTzEqSonzXosASgiAJDJK8+B6QYnH 7q3CpleM4kCvCPPyRAFV8QCTFlz3K6DBTECDC0A+4i0uSURISTUwqkU5lFovyN7i7ZM4I7mA y2KvvhZvzoniOP6JqtvEty6v3HOQ07Haho/33ML7RaaHTtn9/ehzZfeyyl87uMJqt9bKL2o6 m/jZLXPRIV25+tg5oT9U99fOD6w32qD33zb9Ml+IZ7eotYbmCnfd5JfH7DaWlk5adn/OBCsl v7kXNxadmnamtiheiaU4I9FQi7moOBEAgq1xMxcDAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Can i use domain name for oauth2 client id?
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, 29 Aug 2016 15:56:58 -0000

--Apple-Mail=_76546578-EBB3-46C2-B5B4-53ABC26A9B2D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Dots are legal in a client ID (as per the spec), and there=E2=80=99s =
nothing inherently wrong with a client ID that=E2=80=99s a domain name. =
However, how can you be sure it=E2=80=99s google that gets the client ID =
=E2=80=9Cgoogle.com =E2=80=9D? And what if Google =
wants to have two clients?

In many implementations (including ours from MIT ITC), the client ID is =
random (we use a type 4 UUID) and we=E2=80=99ve got a separate field for =
human-readable names (client_name, defined in the dynamic registration =
specification).

 =E2=80=94 Justin

> On Aug 29, 2016, at 12:51 AM, Viruthagiri Thirumavalavan =
 wrote:
>=20
> I'm working on a OAuth2 server project. Can I use domain name for =
generating client_id ?
>=20
> Ex: For instance if Google registering an app in my server, then the =
client_id will be google.com 
> Am i allowed to use dots in client_id? Is it wise to use domain name =
as client_id ? what are the drawbacks?
>=20
> Thanks
> --=20
> Regards,
> Giri
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_76546578-EBB3-46C2-B5B4-53ABC26A9B2D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Dots are legal in a client ID (as per the spec), and =
there=E2=80=99s nothing inherently wrong with a client ID that=E2=80=99s =
a domain name. However, how can you be sure it=E2=80=99s google that =
gets the client ID =E2=80=9Cgoogle.com=E2=80=9D? And what if Google wants to have two =
clients?

In many =
implementations (including ours from MIT ITC), the client ID is random =
(we use a type 4 UUID) and we=E2=80=99ve got a separate field for =
human-readable names (client_name, defined in the dynamic registration =
specification).

 =E2=80=94 Justin

On =
Aug 29, 2016, at 12:51 AM, Viruthagiri Thirumavalavan <giridharanbtech@gmail.com> wrote:

I'm =
working on a OAuth2 server project. Can I use domain name for generating =
client_id ?
Ex: For instance if =
Google registering an app in my server, then the client_id will be =
google.com
Am i allowed to use =
dots in client_id? Is it wise to use domain name as client_id ? what are =
the drawbacks?
Thanks
-- 
Regards,
Giri



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

=

--Apple-Mail=_76546578-EBB3-46C2-B5B4-53ABC26A9B2D--


From nobody Wed Aug 31 06:56:21 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115FC12B005 for ; Mon, 29 Aug 2016 09:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaDEDI6q5ozP for ; Mon, 29 Aug 2016 09:55:36 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D22D12D098 for ; Mon, 29 Aug 2016 09:55:36 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id c15so204152002oig.0 for ; Mon, 29 Aug 2016 09:55:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OjwQk4D75naLU6YAIhtrjCy188852BA3Xn0dazNCDfk=; b=sTZA/977xflCFvjj1HaQWRyRJNbqjIaOFvjCWHbbVxAKpPvSqD5OOMov6fH5g65HUE lCwRAeoAbbQa9ff3IBPPZpjqYY2+OF1xb7+a4A2F8GDGa6LhKdXMU1tFSlkf56qoyCuE s8ZnJP8HPp1joCGULRCv/NgvyFcoTRNCpw0iAOmeSTmXoPbYkvPFYv6OkVQQGCgMADVV Fiym5YxRmItkVRrfjmWvjC6UlRn26qu2LqJzpDFFffQjj+2Fk1zfHpJC14eX9ikKa+c0 43b+/9W9AZqWPzrIYRerYpnRazwp2x6X07P+LBSD3PwVZO/wDvNiaHYP9vIGWaOcjSyc QYOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OjwQk4D75naLU6YAIhtrjCy188852BA3Xn0dazNCDfk=; b=U1YRgyltgeutdeAV/cWihHUuUK6azJ5hUGKQJh7OOZoCNIZBMp23xKI4jJ12mCcVTF ljoiOLgq05RZSrgZp5OQQGAtJt1kD6fbMBkgwIuXwVDvtWuJCI5/LbPDXEqKGcn9hmMg r47sm6F6STLAf92/duN1QSusiK+L170HWtPSSkcaz+emHcX59JmKNDRJDkwjJnt9/DcM SB65UboRqETlrRxctYYibzXOV2wU2Az11W4pK5Pdv8c5Fe7wTuEDrspU9s42F7vkCzCB gGybjrSetJR4/XPO8mJdrJqNN8miPYkAdCYMDw5meLH3lmUhFvY+vP0o+KmgUT9JUk29 Z47A==
X-Gm-Message-State: AE9vXwPucc5KfGSFflTN37siio+049knP4TxXtjrWfpy0NMyx7XhZQfRPheisSF6XUbs639mSDjlnBnXJslsTQ==
X-Received: by 10.202.184.136 with SMTP id i130mr13718349oif.153.1472489735870;  Mon, 29 Aug 2016 09:55:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.108.136 with HTTP; Mon, 29 Aug 2016 09:55:15 -0700 (PDT)
In-Reply-To: <50F0DFCB-31D3-47F8-BC0E-3D52383ACECA@mit.edu>
References:  <50F0DFCB-31D3-47F8-BC0E-3D52383ACECA@mit.edu>
From: Viruthagiri Thirumavalavan 
Date: Mon, 29 Aug 2016 22:25:15 +0530
Message-ID: 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=001a113cd53ea45df2053b38bb5f
Archived-At: 
X-Mailman-Approved-At: Wed, 31 Aug 2016 06:56:19 -0700
Cc: "" 
Subject: Re: [OAUTH-WG] Can i use domain name for oauth2 client id?
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, 29 Aug 2016 16:55:38 -0000

--001a113cd53ea45df2053b38bb5f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks Justin.

I just need a way to identify client_id. I'm planning to use 15 char for
client_id. Can I use first 3 char of domain and then random number for
client ID for the rest 12 char?

I mean something like GOO123456789123 for Google.

Thanks

On Mon, Aug 29, 2016 at 9:26 PM, Justin Richer  wrote:

> Dots are legal in a client ID (as per the spec), and there=E2=80=99s noth=
ing
> inherently wrong with a client ID that=E2=80=99s a domain name. However, =
how can
> you be sure it=E2=80=99s google that gets the client ID =E2=80=9Cgoogle.c=
om=E2=80=9D? And what if
> Google wants to have two clients?
>
> In many implementations (including ours from MIT ITC), the client ID is
> random (we use a type 4 UUID) and we=E2=80=99ve got a separate field for
> human-readable names (client_name, defined in the dynamic registration
> specification).
>
>  =E2=80=94 Justin
>
> On Aug 29, 2016, at 12:51 AM, Viruthagiri Thirumavalavan <
> giridharanbtech@gmail.com> wrote:
>
> I'm working on a OAuth2 server project. Can I use domain name for
> generating client_id ?
>
> Ex: For instance if Google registering an app in my server, then the
> client_id will be google.com
>
> Am i allowed to use dots in client_id? Is it wise to use domain name as
> client_id ? what are the drawbacks?
> Thanks
> --
> Regards,
> Giri
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>


--=20
Regards,
Giri

--001a113cd53ea45df2053b38bb5f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks Justin.=C2=A0

I just need a way =
to identify client_id. I'm planning to use 15 char for client_id. Can I=
 use first 3 char of domain and then random number for client ID for the re=
st 12 char?

I mean something like GOO123456789123 =
for Google.

Thanks

On Mon, Aug 29, 2016 at 9:26 PM, Just=
in Richer <jricher@mit.edu> wrote:
Dots are legal in a client ID =
(as per the spec), and there=E2=80=99s nothing inherently wrong with a clie=
nt ID that=E2=80=99s a domain name. However, how can you be sure it=E2=80=
=99s google that gets the client ID =E2=80=9Cgoogle.com=E2=80=9D? And what if Google wants to have=
 two clients?

In many implementations (including ours fr=
om MIT ITC), the client ID is random (we use a type 4 UUID) and we=E2=80=99=
ve got a separate field for human-readable names (client_name, defined in t=
he dynamic registration specification).

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

On Aug 29, 2016, at 12:51 AM, Viruthagiri Thirumavalavan <<=
a href=3D"mailto:giridharanbtech@gmail.com" target=3D"_blank">giridharanbte=
ch@gmail.com> wrote:

I'm working on a OAuth2 server project. Can=
 I use domain name for generating client_id ?
Ex: For in=
stance if Google registering an app in my server, then the client_id will b=
e google.com<=
/a>
Am i allowed to use dots in client_id? Is it wise to use d=
omain name as client_id ? what are the drawbacks?
-=
- 
Regards,Giri



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




-- 
Regards,
Giri




--001a113cd53ea45df2053b38bb5f--


From nobody Wed Aug 31 19:21:08 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A6D12D7C4 for ; Wed, 31 Aug 2016 19:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 BBJBT2eTkbkL for ; Wed, 31 Aug 2016 19:21:06 -0700 (PDT)
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 A0E4712B068 for ; Wed, 31 Aug 2016 19:21:05 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id l94so121706428ual.0 for ; Wed, 31 Aug 2016 19:21:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to; bh=JJ7pj106d6HQHIEsz94aNR3JpwCcAizXfAhNZqsIUmg=; b=XQIC5fGsN5ZbpvCURJImT2kJCeYImzMa3Ea/OuHIq0mUQJbJwMjwqAOC6O69UH+g25 ObflQexy2J2goAEvWIK65sODI3F/mI6SyCo48X7rqQr577kvQTEZxTt5oWy3K/B9abhs Ds9Kra2T3aa6wsTVI5uGF/kdTfxkiMqgwzymJsEIAiOXYo8MrBGgQvMY9/paL/JsQaSm RNlfFMjI5AX+3bmbgl66+G2OIptBfkbm8a7LHeIvAxX4niahZ9L+vUY6XHmbbl4eu47d 4t9HfwqSInrYiKVvmZZG+l/E71N2uGsj0OF5IEKaY7FctaXmC7drol691ALEImstb0Xt IVFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JJ7pj106d6HQHIEsz94aNR3JpwCcAizXfAhNZqsIUmg=; b=PpFeCJlf2uWKjaT6xGnZoYcYUMIgzxkqI7nfX0kr5BhJgcoeRo518lf4Tuk9DsthMe uDUhMrTLH+SIQWJanJ+fkvfaHKbd/GXepJarO1g/NnmFsx5IsNJUsov5RVpuivKJAwoH 9QqFFLxW521YEqFp/ZpTj6NEyv+Ghl8ZzMWcJnMCzeE1xJ0MppvPJYQEoMg40jW7Cnaw p2bNuDd8UDzqnOMNk3H8PeuNaytkvo/EcmOe/5QVxeyyX9LDdcvhI1c+5fHnIMKoU4u8 ZWi6LEbZwwes0EY4ax4jklnTWNnQ3uJJUyuB1TyEn0tWks18ep/+/8bph8Gsqvp8HNaS f7Lg==
X-Gm-Message-State: AE9vXwNNCqfczSDrJ0WUUSuC5VTsFqpqxbnu5D1u7Dc64avTuejGA3qljjMVe0kEJKN6bNYlr3bJDwQ/RIN/5g==
X-Received: by 10.176.1.97 with SMTP id 88mr7949888uak.147.1472696464648; Wed, 31 Aug 2016 19:21:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.107.195 with HTTP; Wed, 31 Aug 2016 19:21:04 -0700 (PDT)
From: mehtab shar 
Date: Wed, 31 Aug 2016 18:21:04 -0800
Message-ID: 
To: oauth@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: [OAUTH-WG] api on
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, 01 Sep 2016 02:21:07 -0000

my tweets block please on my tweets